导读   

PostgreSQL集群通常由两种类型的服务器组成：主服务器和备份服务器。

主服务器是集群中的主要工作节点，负责处理所有的写入操作和读取操作。备份服务器则是作为主服务器的备份。集群中的主备服务器之间需进行数据同步，要确保备份服务器上的数据与主服务器是实时同步的，当主服务器故障或失效时，备份服务器会接管主服务器的工作。PostgreSQL集群中的数据同步通常采用流复制的方式实现。

流复制是一种异步的数据复制方式，主服务器将数据变更写入wal日志文件，并将wal日志文件发送给备份服务器，备份服务器接收到wal日志文件后，将其应用到自己的数据库中，以保证自己的数据与主服务器的数据保持一致。流复制的优点是数据同步速度快，缺点是可能存在数据同步延迟，在主服务器故障时，备份服务器上的数据未完全同步，可能会导致数据丢失或数据不一致的情况。

本文结合实际生产中PG数据库集群脑裂问题，对PG流复制集群中脑裂现象发生的原因、影响因素、处理过程、避免脑裂建议等进行梳理总结。

一. 场景描述

环   境：xx系统pg数据库

版   本：pg 12.5

主   库：22.*.*.156

同步备：22.*.*.157

异步备：22.*.*.158

（注：以下描述均以156、157、158命名各节点，主机名末尾分别为a、b、c）

二. 故障现象

统一监控告警目标为156主库，告警如下：

第一次告警为could not receive data from WAL stream流复制告警

第二次告警为[PG Cluster ERROR] Node Failed

三. 信息整理

从156上查看集群状态，显示158节点stopped，157为主，156为同步备，但是统一监控无158相关告警。

从158上查看集群状态，发现集群均正常，但是此时158为主。

登录普罗米修斯查看如下图：显示—157和158均为主节点。

查看流复制状态

首先在备库查看流复制，三个节点均需查看，显示结果是156查询流复制结果为正常，157和158则显示异常，报错指出该节点不是备节点；后在主库查流复制，执行节点为157和158，显示结果表明157查询流复制结果为正常，而158无结果。那么一定程度上可以判断得出——目前集群主节点为157。

四. 故障分析

由信息整理部分的相关4点判断集群发生脑裂，申请3个节点高权进行详细排查：

1.  判断之前哪个节点是主

通过查看corosync.log日志，grep master查看之前哪个节点是主节点

在158上查看cat /var/log/cluster/corosync.log |grep Master由下图判断在3点之前主节点为158c节点

在156上查看more /var/log/cluster/corosync.log |grep Master由下图可知6点以后主节点已经切换为157b节点由此可知：在切换前的主为158c，切换后的主为157b

2.  查看目前业务连接数情况查看业务连接数多的进程，登录157和158执行ps -ef |grep postgres通过连接数判断目前157连接的进程数多（主要是idle连接数），而158没有相关进程，说明目前业务以157为主。

3.  系统层面确认脑裂通过系统查看vip连接情况，目前master-vip为159

157和158执行ipa命令发现，目前master-vip在157和158上都有，确认为脑裂。

五. 故障处理

由于157目前业务进程均在，且流复制正常，所以目前需要进行恢复操作的为158节点。

1、停掉158节点pg数据库集群服务，root执行pcs cluster stop

然后启动单节点集群服务，root执行pcs cluster start

2、发现集群服务不能正常启动，ip a查看master-vip依旧在158节点，则重启故障节点，通过一体化关停主机进行重启（如果是虚机没有重启成功则需要通过云管）

重启后ip a查看master-vip已经不在该节点；

再次执行pcs cluster start依旧不能正常启动；

3、节点仍未恢复，则重建备节点

登录一体化执行“pg_recover_slave”进行恢复，发现脚本执行长时间无结果，可能脚本存在问题（长时间没反应，是因为数据库较大，需要登陆主库执行checkpoint）

则在158节点手动重建恢复

cd /pgdb

mv /pgdb/pgdata /pgdb/pgdata.bak（空间充足）

rm -rf ./pgdata（空间不足）

cls_rebuild_slave

后续进行正常恢复重建完成后，查看数据库状态cls_status。

此时数据库集群恢复正常，158为异步备，恢复正常。

查看流复制如下，流复制恢复正常，确认业务恢复正常后，清理日志，结束维护期。

六. 问题总结

当查看集群状态时，发现有两个主节点（节点角色状态异常），或者快查登录到对应服务器查看vip挂载情况可快速判断集群是否脑裂。注意务必和应用保持实时沟通，确认在不影响业务的节点进行集群异常节点恢复，随时确认业务情况，集群正常运行后，确认数据传输恢复正常（流复制正常）。

七. 异常应对

关闭主节点后，如果主节点无法正常启动，可用如下方法做进一步尝试：

pcs resource cleanup master-group//清理集群故障状态重新选主pcs resource cleanup msPostgresql//清理失败信息重置资源状态rm /var/lib/pgsql/tmp/PGSQL.lock//删除问题节点锁文件

如欲了解更多，请登录365bet足球比分官方网站:lazy.lvyanbo.com