我正在寻找更详细的指导/其他人在 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）我有三个选择。
接受它，并在我的应用程序中处理 SQL 命令的重试。可能，但似乎需要付出很大的努力，如果我弄错了，就会产生很多可能的错误。
打开 keepalives 并让 npgsql 本身在坏连接失败时相对较快地“失败”。我什至不确定这是否有效或者是否会导致进一步的问题。
完全关闭客户端连接池。这似乎是官方建议，但出于性能原因我不愿意这样做，对于 Npgsql 来说，必须为每个会话打开到 pgbouncer 的连接似乎非常浪费 - 并且与我使用 SQL 等其他 RDBMS 的所有经验背道而驰服务器。
我的这些选择之一是否走在正确的轨道上？或者我错过了什么？
您通常走在正确的轨道上，并且您的分析似乎很准确。一些评论：
选项 2（关闭 keepalive）将有助于删除 Npgsql 池中已损坏的空闲连接。正如您所编写的，您的应用程序仍然会出现一些故障（因为一些不良的空闲连接可能无法及时删除）。没有特别的理由认为这会导致进一步的问题 - 这应该是非常安全的打开。
选项 3 对于性能来说确实是有问题的，因为每次需要数据库连接时都必须建立到 pgbouncer 的 TCP 连接。它也不会提供 100% 的防故障机制，因为 pgbouncer 在使用连接时仍然可能会丢失。
归根结底，您会询问面对任意网络/服务器故障时的弹性，这并不是一件容易实现的事情。处理此问题的唯一 100% 可靠方法是在您的应用程序中，通过专用层在发生瞬态异常时重试操作。您可能想看看Polly https://github.com/App-vNext/Polly，并注意 Npgsql 通过公开一个对我们有帮助的IsTransient http://www.npgsql.org/doc/api/Npgsql.NpgsqlException.html#Npgsql_NpgsqlException_IsTransient异常可以用作重试的触发器（Entity Framework Core 也包含类似的“重试策略”）。如果您确实走这条路，请注意，正确处理交易特别困难。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
