EN 联系我们加入我们
典型案例
您现在的位置:首页 > 典型案例
【案例分享】某业务平台PG数据库集群脑裂问题分析

 

导读   


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相关告警。


111小.jpg


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


222小.jpg


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


3.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节点

4.png


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

5.png


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


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

1698287432293423.png


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

7.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。

8改.jpg

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

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

9.png


六. 问题总结


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




七. 异常应对



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

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



如欲了解更多,请登录安图特官方网站:www.antute.com.cn

版权所有 安图特(北京)科技有限公司 备案号:京ICP备17074963号-1
技术支持:创世网络