导读
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相关告警。
![1698287292657927.jpg 111小.jpg](/data/upload/image/20231026/1698287292657927.jpg)
从158上查看集群状态,发现集群均正常,但是此时158为主。
![1698287317608895.jpg 222小.jpg](/data/upload/image/20231026/1698287317608895.jpg)
登录普罗米修斯查看如下图:显示—157和158均为主节点。
![1698287355914087.png 3.png](/data/upload/image/20231026/1698287355914087.png)
查看流复制状态
首先在备库查看流复制,三个节点均需查看,显示结果是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节点
![1698287393113410.png 4.png](/data/upload/image/20231026/1698287393113410.png)
在156上查看more /var/log/cluster/corosync.log |grep Master由下图可知6点以后主节点已经切换为157b节点由此可知:在切换前的主为158c,切换后的主为157b
![1698287410831919.png 5.png](/data/upload/image/20231026/1698287410831919.png)
2. 查看目前业务连接数情况查看业务连接数多的进程,登录157和158执行ps -ef |grep postgres通过连接数判断目前157连接的进程数多(主要是idle连接数),而158没有相关进程,说明目前业务以157为主。
3. 系统层面确认脑裂通过系统查看vip连接情况,目前master-vip为159
![1698287470693707.png 1698287432293423.png](http://p2yu.amuralha.net/data/upload/image/20231026/1698287470693707.png)
157和158执行ipa命令发现,目前master-vip在157和158上都有,确认为脑裂。
![1698287512558012.png 7.png](/data/upload/image/20231026/1698287512558012.png)
五. 故障处理
由于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。
![1698288769512347.jpg 8改.jpg](/data/upload/image/20231026/1698288769512347.jpg)
此时数据库集群恢复正常,158为异步备,恢复正常。
查看流复制如下,流复制恢复正常,确认业务恢复正常后,清理日志,结束维护期。
![1698288788601976.png 9.png](/data/upload/image/20231026/1698288788601976.png)
六. 问题总结
当查看集群状态时,发现有两个主节点(节点角色状态异常),或者快查登录到对应服务器查看vip挂载情况可快速判断集群是否脑裂。注意务必和应用保持实时沟通,确认在不影响业务的节点进行集群异常节点恢复,随时确认业务情况,集群正常运行后,确认数据传输恢复正常(流复制正常)。
七. 异常应对
关闭主节点后,如果主节点无法正常启动,可用如下方法做进一步尝试:
pcs resource cleanup master-group//清理集群故障状态重新选主pcs resource cleanup msPostgresql//清理失败信息重置资源状态rm /var/lib/pgsql/tmp/PGSQL.lock//删除问题节点锁文件
如欲了解更多,请登录365bet足球比分官方网站:p2yu.amuralha.net