时间戳

首页 > 解决方案 > Npgsql 与 Kubernetes 上的 Pgbouncer - 池化和 keepalives

postgresql - Npgsql 与 Kubernetes 上的 Pgbouncer - 池化和 keepalives

问题描述

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

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

在此处输入图像描述

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

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

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

正如我所看到的（并查看 中的建议https://www.npgsql.org/doc/compatibility.html），我有三个选择。

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

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

  3. 完全关闭客户端连接池。这似乎是官方的建议，但出于性能原因，我不愿意这样做，对于 Npgsql 来说，必须为每个会话打开与 pgbouncer 的连接似乎非常浪费 - 并且与我使用其他 RDBMS（如 SQL）的所有经验背道而驰服务器。

我在这些选项之一的正确轨道上吗？还是我错过了什么？

标签： postgresqlasp.net-corekubernetesnpgsqlpgbouncer

解决方案

您通常走在正确的轨道上，您的分析似乎是准确的。一些评论：

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

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

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

推荐阅读