0

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

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

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

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

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

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

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

4

1 回答 1

0

那很有趣

如果总结它的要点，

它是 OPS 团队基础设施备份的一部分

现在整个过程是这样的：

设置环境： 我们在 VMWare vCenter 集群上运行本地部署，在基础设施端使用 VMWare VM 快照和 Veeamm VM 备份，其中 vmdk 文件\ESXi 数据存储驻留在基于 NFS 的 NetApp 存储上。

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

粗略说明： 丢包图

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

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

节点每晚在特定时间分离

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

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

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

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

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

建议了一个解决方案，包括解决此链接最后引用中提出的问题，但目前，我们删除了对敏感 VM 的 Veeam 备份的使用，直到可以在本地验证该解决方案（如果尝试并修复，将在未来更新问题）

其他事件文档：类似问题案例、来自 Veeam 的建议解决方案信息、第三方站点解决方案（与我看到的临时修复问题大致相同）、Reddit 线程确认问题并建议选项

于 2021-12-02T22:31:48.870 回答