pgpool 节点无缘无故分离？
pgpool node detached for no reason?
我在 VM 上有一个双节点 PostgreSQL 集群 运行，其中每个 VM 都运行 pgpool 服务和 Postgres 服务器。
由于内存配置不足，Postgres 服务器崩溃了，所以我在 postgresql.conf 文件中增加了 VM 内存和更改的 Postgres 内存配置。由于该内存发生变化，从属 pgpool 节点每晚在特定时间分离，尽管在查看有关 CPU、负载、进程磁盘使用或内存的 node_exporter 指标时没有显示任何峰值或突然变化。
从节点分离发生在以前，但不是日复一日。我偶然发现了 and read this part 有关故障转移的文档，但是由于 Postgres 服务器没有崩溃并且与从属节点的现有连接正在工作（它继续为现有连接提供服务但没有接受新连接）所以网络问题似乎无关紧要，尤其是在咨询了我们的 OPS 团队关于他们是否注意到任何异常网络或 DNS activity 可以解释这一点之后。不幸的是，他们没有注意到任何有趣的发现。
我在每个节点上都有 pg_exporter、postgres_exporter 和 node_exporter 来监视服务器和 VM 行为，我应该寻找什么来调试它？我应该要求我们的 OPS 团队具体检查什么？我们的 pgpool 日志文件只说明访问另一个节点失败但没有确切原因，正如上述文档所说：
Pgpool-II does not distinguish each case and just decides that the
particular PostgreSQL node is not available if health check fails.
它仍然是一个 network\DNS 问题吗？如果是这样。我该如何确认？
感谢阅读并花时间帮助我解决这个难题
很有趣
如果总结它的要点，
它是 OPS 团队基础设施备份的一部分
现在整个过程是这样的：
设置氛围：
我们 运行 本地部署在 VMWare vCenter 集群之上，使用 VMWare VM 快照和 Veeamm VM 备份在基础设施端进行备份，其中 vmdk files\ESXi 数据存储驻留在基于 NFS 的 NetApp 存储上。
在 Node Exporter Full 仪表板中检查节点导出器指标时，我看到网络流量在过去几个月中持续下降约 5 到 15 分钟，每秒最多 2 个数据包，现象长度急剧增加在上个月（大约在深夜的同一时间）。
粗略图：
在与我们的 OPS 团队再次核实后，他们表示它可能是主机 configurations\Veeam 备份。
事实证明，由于 VM 的存储（包括 运行 作为 Veeam 备份的存储）是通过网络连接的，而不是直接连接在 ESXi 主机上，因此最终快照 saved\consolidated在那个深夜-
node detaches every night at a specific time
NFS 使用磁盘锁定（将 IOP 限制为现有数据）的方式以及 Veeam 备份的高 IOP 要求导致服务器 hang\freeze，有时甚至在极少数情况下甚至会重启 VM。这是来自 Veeam issue doc:
的引述
The snapshot removal process significantly lowers the total IOPS that can be delivered by the VM because of additional locks on the VMFS storage due to the increase in metadata updates
the snapshot removal process will easily push that into the 80%+ mark and likely much higher. Most storage arrays will see a significant latency penalty once IOP's get into the 80%+ mark which will of course be detrimental to application performance.
This issue occurs when the target virtual machine and the backup appliance [proxy] reside on two different hosts, and the NFSv3 protocol is used to mount NFS datastores. A limitation in the NFSv3 locking method causes a lock timeout, which pauses the virtual machine being backed up [during snapshot removal].
显然，这至少会干扰 Postgres 的功能，特别是配置为具有复制功能的集群时，需要 Postgres 服务器之间几乎保持连接。 A similar thread 在 SO 上使用不同的数据库服务器
建议的解决方案包括解决 this link 中最后引述中提出的问题，但目前我们删除了对敏感 VM 的 Veeam 备份的使用，直到该解决方案可以在本地验证（将如果尝试并解决了问题，将来会更新）
其他事件文档：similar issue case, suggested solution info from Veeam, third party site solution (around the same problem as a temp fix as I see it), Reddit thread acknowledging the issue and suggesting options
我在 VM 上有一个双节点 PostgreSQL 集群 运行，其中每个 VM 都运行 pgpool 服务和 Postgres 服务器。
由于内存配置不足，Postgres 服务器崩溃了，所以我在 postgresql.conf 文件中增加了 VM 内存和更改的 Postgres 内存配置。由于该内存发生变化，从属 pgpool 节点每晚在特定时间分离，尽管在查看有关 CPU、负载、进程磁盘使用或内存的 node_exporter 指标时没有显示任何峰值或突然变化。
从节点分离发生在以前，但不是日复一日。我偶然发现了
我在每个节点上都有 pg_exporter、postgres_exporter 和 node_exporter 来监视服务器和 VM 行为，我应该寻找什么来调试它？我应该要求我们的 OPS 团队具体检查什么？我们的 pgpool 日志文件只说明访问另一个节点失败但没有确切原因，正如上述文档所说：
Pgpool-II does not distinguish each case and just decides that the particular PostgreSQL node is not available if health check fails.
它仍然是一个 network\DNS 问题吗？如果是这样。我该如何确认？
感谢阅读并花时间帮助我解决这个难题
很有趣
如果总结它的要点，
它是 OPS 团队基础设施备份的一部分
现在整个过程是这样的：
设置氛围： 我们 运行 本地部署在 VMWare vCenter 集群之上，使用 VMWare VM 快照和 Veeamm VM 备份在基础设施端进行备份，其中 vmdk files\ESXi 数据存储驻留在基于 NFS 的 NetApp 存储上。
在 Node Exporter Full 仪表板中检查节点导出器指标时，我看到网络流量在过去几个月中持续下降约 5 到 15 分钟，每秒最多 2 个数据包，现象长度急剧增加在上个月（大约在深夜的同一时间）。
粗略图：
在与我们的 OPS 团队再次核实后，他们表示它可能是主机 configurations\Veeam 备份。
事实证明，由于 VM 的存储（包括 运行 作为 Veeam 备份的存储）是通过网络连接的，而不是直接连接在 ESXi 主机上，因此最终快照 saved\consolidated在那个深夜-
node detaches every night at a specific time
NFS 使用磁盘锁定（将 IOP 限制为现有数据）的方式以及 Veeam 备份的高 IOP 要求导致服务器 hang\freeze，有时甚至在极少数情况下甚至会重启 VM。这是来自 Veeam issue doc:
的引述The snapshot removal process significantly lowers the total IOPS that can be delivered by the VM because of additional locks on the VMFS storage due to the increase in metadata updates
the snapshot removal process will easily push that into the 80%+ mark and likely much higher. Most storage arrays will see a significant latency penalty once IOP's get into the 80%+ mark which will of course be detrimental to application performance.
This issue occurs when the target virtual machine and the backup appliance [proxy] reside on two different hosts, and the NFSv3 protocol is used to mount NFS datastores. A limitation in the NFSv3 locking method causes a lock timeout, which pauses the virtual machine being backed up [during snapshot removal].
显然，这至少会干扰 Postgres 的功能，特别是配置为具有复制功能的集群时，需要 Postgres 服务器之间几乎保持连接。 A similar thread 在 SO 上使用不同的数据库服务器
建议的解决方案包括解决 this link 中最后引述中提出的问题，但目前我们删除了对敏感 VM 的 Veeam 备份的使用，直到该解决方案可以在本地验证（将如果尝试并解决了问题，将来会更新）
其他事件文档：similar issue case, suggested solution info from Veeam, third party site solution (around the same problem as a temp fix as I see it), Reddit thread acknowledging the issue and suggesting options