postgresql - Kubernetes 上带有 Pgbouncer 的 Npgsql - 池化和保活

Question

我正在寻找更详细的指导/其他人在 Pgbouncer 的生产中使用 Npgsql 的经验。

基本上，我们使用 GKE 和 Google Cloud SQL 进行了以下设置:

现在 - 我已经使用本地连接池配置了 npgsql，就好像 pgbouncer 没有到位一样。我已将 pgbouncer 作为部署添加到我的 GKE 集群中，因为 Google SQL 的最大连接限制非常低 - 为了能够在 Kubernetes 内水平扩展我的应用程序，我需要防止它不堪重负。

我的问题是其中一个 pgbouncer pod 死机时的可靠性问题(由于节点故障或我正在扩大/缩小规模)。

发生这种情况时 (1) 应用程序 pod 中来自客户端连接池的所有现有打开连接不会立即关闭 (2) - 并且基本上会导致我的应用程序在尝试执行命令时出现异常。不理想!

在我看来(并查看了 https://www.npgsql.org/doc/compatibility.html 上的建议)我有三个选择。

1. 忍受它，并在我的应用程序中处理 SQL 命令的重试。可能，但似乎需要付出很多努力，如果我弄错了，可能会产生很多错误。 p>

2. 打开 keep alives 并让 npgsql 本身相对快速地“失败”连接失败。我什至不确定这是否有效，或者是否会导致进一步问题。

3. 完全关闭客户端连接池。这似乎是官方建议，但出于性能原因我不愿意这样做，Npgsql 必须打开似乎非常浪费为每个 session 连接到 pgbouncer - 这与我使用其他 RDBMS(如 SQL Server)的所有经验背道而驰。

我选择这些选项之一是否正确？还是我遗漏了什么？

Answer 1

您的方向大体上是正确的，您的分析似乎很准确。一些评论:

选项 2(生成 keepalive)将有助于删除 Npgsql 池中已断开的空闲连接。正如您编写的那样，您的应用程序仍然会出现一些故障(因为可能无法及时删除一些不良的空闲连接)。没有特别的理由认为这会导致更多问题 - 打开它应该是非常安全的。

选项 3 确实对 perf 有问题，因为每次需要数据库连接时都必须建立到 pgbouncer 的 TCP 连接。它也不会提供 100% 的防故障机制，因为 pgbouncer 在连接正在使用时可能仍然会退出。

归根结底，您是在询问面对任意网络/服务器故障时的弹性，这不是一件容易实现的事情。处理这个问题的唯一 100% 可靠的方法是在您的应用程序中，通过一个专用层，该层将在发生暂时性异常时重试操作。你可能想看看 Polly ，并注意 Npgsql 通过公开一个 IsTransient 来帮助我们。可以用作重试触发器的异常(Entity Framework Core 也包含类似的“重试策略”)。如果您确实走这条路，请注意事务特别难以正确处理。