网络故障导致主从脑裂

原创进击的CJR 2023-05-25

4543

出现异常

收到告警，某个一主一从的库发生了主从异常，登录监控发现主从发生了切换，切换前B是主库，A是从库。现在状态是A主，B从。

登录库检查发现主从实际上是挂了，B实际并没有作为从库挂到A上，此时两个库都是read_only=on的状态。

检查日志，发现网络波动，主从断开。

B库日志，B上接收不到从库返回，因此停止了binlog_dump进程

A库上IO线程和SQL线程异常

思考为什么新的主从没有搭建成功

检查两个库的GTID信息

发现原主B上 server_UUID 为

db**********************B 比A上的大，

且A上 server_UUID为dba*********************A 已经有新的gtid，且该UUID在B上并没有

说明断开后两个数据库都写入了新数据，此时数据不一致，A切换为新主后，

B上由于本身的GTID（server_UUID 为

db**********************B）比A大因此成为不了A的从库。

（1）先修复A上缺失的数据，

在A上执行

stop slave；CHANGE MASTER TOMASTER_HOST='B的host',MASTER_USER='B的同步用户',MASTER_PASSWORD='B的同步用户密码',MASTER_PORT=端口,MASTER_AUTO_POSITION=1;start slave ;

此时A上 db********************B 的GTID已经和B一致。

但是主从依然报错，因为server_UUID为dba**************A 的GTID B上还没有

（2）将主切换到A上，修复B缺失GTID

CHANGE MASTER TOMASTER_HOST='A的host',MASTER_USER='A的同步用户',MASTER_PASSWORD='A的同步用户密码',MASTER_PORT=端口,MASTER_AUTO_POSITION=1;start slave ;

（3）

此时主从报错1236

该拉取的GTID的binlog文件已经不存在了

（4）

核实缺失的binlog是否会导致业务数据丢失，如果不影响，执行下一步

（5）

跳过事务

在B上跳过事务

stop slave;

set sql_log_bin=off;

set gtid_next='';

BEGIN;
COMMIT;

SET GTID_NEXT='AUTOMATIC';

「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」

关注作者