pgpool 节点无缘无故分离？

Question

我有一个在 VM 上运行的双节点 PostgreSQL 集群，其中每个 VM 都运行 pgpool 服务和 Postgres 服务器。

由于内存配置不足，Postgres 服务器崩溃了，所以我在 postgresql.conf 文件中调整了 VM 内存和更改的 Postgres 内存配置。由于该内存发生变化，因此从属 pgpool 节点每晚在特定时间分离，但在查看有关 CPU、负载、进程磁盘使用或内存的 node_exporter 指标时，并未显示任何峰值或突然变化。

从节点分离发生在之前但不是日复一日。我偶然发现了this thread 并阅读了有关故障转移的文档的this part，但是由于 Postgres 服务器没有崩溃并且与从节点的现有连接正在工作（它继续提供现有连接但没有采用新连接) 所以网络问题似乎无关紧要，尤其是在咨询了我们的 OPS 团队之后，他们是否注意到任何异常的网络或 DNS 活动可以解释这一点。不幸的是，他们没有注意到任何有趣的发现。

我在每个节点上都有pg_exporter、postgres_exporter 和node_exporter 来监控服务器和VM 行为，我应该寻找什么来调试它？我应该要求我们的 OPS 团队具体检查什么？我们的 pgpool 日志文件仅说明无法访问其他节点，但没有确切原因，如上述文档所述：

Pgpool-II 不区分每种情况，只是决定 如果健康检查失败，特定 PostgreSQL 节点将不可用。

这仍然是网络\DNS 问题吗？如果是这样。我该如何确认？

感谢您阅读并花时间帮助我解决这个难题

Answer 1

这很有趣

如果总结它的要点，

它是 OPS 团队基础架构备份的一部分

现在整个过程是这样的：

营造氛围： 我们在 VMWare vCenter 集群的基础上运行本地备份，使用 VMWare 虚拟机快照和 Veeamm 虚拟机备份，其中 vmdk 文件\ESXi 数据存储驻留在基于 NFS 的 NetApp 存储上。

在Node Exporter Full Dashboard 中检查节点导出器指标时，我发现在过去几个月中，网络流量在大约 5 到 15 分钟内以每秒最多 2 个数据包的顺序下降，上个月现象长度显着增加（大约在深夜同一时间）。

粗略说明：

在与我们的 OPS 团队再次核对后，他们表示可能是主机配置\Veeam Backups。

事实证明，由于虚拟机的存储（包括运行 Veeam 备份的存储）是通过网络连接的，而不是直接连接到 ESXi 主机上，所以最终快照保存\整合在深夜 -

节点每晚在特定时间分离

由于 NFS 使用磁盘锁定（将 IOP 限制为现有数据）的方式以及 Veeam 备份的高 IOP 要求导致服务器挂起\冻结，有时甚至在极少数情况下甚至会重新启动 VM。这是Veeam issue doc的引述：

由于元数据更新增加导致 VMFS 存储上的额外锁定，快照删除过程显着降低了 VM 可以交付的总 IOPS

快照删除过程很容易将其推入 80%+ 标记，并且可能更高。一旦 IOP 达到 80%+ 标记，大多数存储阵列都会出现显着的延迟损失，这当然会损害应用程序的性能。

当目标虚拟机和备份设备 [代理] 位于两个不同的主机上，并且使用 NFSv3 协议装载 NFS 数据存储时，会出现此问题。 NFSv3 锁定方法的限制会导致锁定超时，从而暂停正在备份的虚拟机 [在删除快照期间]。

显然，这至少会干扰 Postgres 功能，特别是配置为具有复制的集群，需要在 Postgres 服务器之间建立近乎恒定的连接。 A similar thread 在 SO 上使用不同的数据库服务器

建议的解决方案包括解决this link 中最后引用中提出的问题，但我们暂时取消了对敏感 VM 的 Veeam 备份的使用，直到可以在本地验证该解决方案（将在未来更新如果尝试并解决了问题）

其他事件文档：similar issue case、suggested solution info from Veeam、third party site solution（与我看到的临时修复问题大致相同）、Reddit thread acknowledging the issue and suggesting options