真实案例：主备切换数据不一致分析

Posted 2022-04-28 进击的CJR

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了真实案例：主备切换数据不一致分析相关的知识，希望对你有一定的参考价值。

故障复盘

基于一套主从的MHA环境，A为现主库，B为现从库。其中

A的uuid是5a56.....7df

B的uuid是6a56.....7df

（1）基于MHA的一主一从环境，演练主库宕机，主备切换

VIP目前在A上，提供给业务使用，模拟主库宕机

systemctl stop mysqld

主库宕机后，观察到VIP正常飘移到B库上，业务正常使用，此时，重启A库，企图将A库重启后重新加入集群，并启动MHA。

启动A库后，将A库作为从库加入到新主B，出现1032报错。

A库信息如下

真实案例：主备切换数据不一致分析_半同步

B库信息如下

真实案例：主备切换数据不一致分析_binlog_02

发现此刻的从库的GTID_SET 5a开头的那个少了一个事务,也就是说旧主A没有将事务全部同步到旧从B，导致现在B少了一个事务，就切换为新主了。

此刻想法就是先尝试将A库没有同步到B库的事务先拉过去，采用主从的方式，将A库进行stop slave操作，然后将B库重新指向为A的从库，这样就将B库缺少的事务拉过去了，

再次将B库进行stop slave 操作，将A库 start slave 发现依然报错。

分析：由于B此前未开启read_only，很有可能，A还是主的时候，B上面有写新数据进去。

（2）备库只读状态下，演练主库宕机，主备切换

（1）将B全备用于恢复A

（2）将A的read_only打开为ON，禁止写入 set global read_only=on；

（3）重新开启MHA，此时B为主，A为从库

（4）将两个库的配置文件read_only均打开，修改MHA master_ip_failover脚本，切换为主的时候，才将read_only关闭。避免从库写入数据。

注意：此时是B主，A从，测试挂掉主库B

现VIP在B库上，A为从库，测试将B库宕机，VIP飘移到A库。业务正常使用，这个时候，将B库重启

观察此刻A库上的gtid信息如下图

真实案例：主备切换数据不一致分析_mysql_03

而B库重启后的gtid信息如下

真实案例：主备切换数据不一致分析_主从_04

可以看到B库原来是主库，uuid是6a，B的gtid在本地库执行的gno比A多了一个26010，A库上只有26009。

依然出现了新主库比旧主库少了一个事务的情况，并且在修改从库只读的情况下，将挂掉的旧主重新加入主从依然是报错1032。

分析：可能是全备恢复的时候，从库没有进行purge操作，导致gtid_executed表在导入数据的过程中被覆盖。一旦从库再次重启，读取gtid_executed表就会得到错误的gtid_executed变量，导致启动失败。

（3）重做备库，将备库gtid_executed可能导致的问题排除

此刻A是主，B是备

（1）停止主从

（2）主库A进行reset master

（3）主库A进行全备，并传输到备库B

（4）将B库reset master

（5）在B库上执行purge操作

真实案例：主备切换数据不一致分析_一致性_06

（6）在B库上执行reset slave all

（7）重搭主从

CHANGE MASTER TO
MASTER_HOST=*******,
MASTER_USER=repl,
MASTER_PASSWORD=******,
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
start slave ;

（8）修复MHA配置文件，重启MHA

此刻A为主库，VIP在主库，提供给业务使用

测试挂掉主库A，此刻A库挂掉，VIP飘移到B上，重启A库，试图重新加入到主从，报错

分析：A库依然比B库多了一个事务，且报错也是1032，解析原当前主库B库该位点的binlog，是一条update信息，而该表在A库中是空表，所以报错：1032错误要更新的数据不存在

真实案例：主备切换数据不一致分析_mysql_08

查看从A库dump出来的备份文件，查看该表是有在备份时候有记录，发现备份出来的时候是有的

真实案例：主备切换数据不一致分析_主从_09

解析B库的所有binlog信息，并没有发现有对该表进行drop ，detete，或者truncate 操作。

可以大概猜得到应该是主库A备份出来的时候数据还在，而主库A挂之前，该表被清空的操作，并没有同步到从库。所以出现也gtid比新主库多了一个事务，且主从1032的错误，因为新主对该表的update操作无法在新从，也就是旧主A上执行。

验证：

解析A库binlog可以看到

真实案例：主备切换数据不一致分析_binlog_10

（4）尝试增强半同步的方式

安装半同步的插件
主库
INSTALL PLUGIN rpl_semi_sync_master SONAME semisync_master.so;
从库
INSTALL PLUGIN rpl_semi_sync_slave SONAME semisync_slave.so;
show plugins;
查看是否安装成功

半同步需要在主从同时开启
主库
SET GLOBAL rpl_semi_sync_master_enabled = 1;
从库
SET GLOBAL rpl_semi_sync_slave_enabled = 1;
以上的启动方式是在命令行操作，也可写在配置文件中。

重启从库的IO线程
STOP SLAVE IO_THREAD;
START SLAVE IO_THREAD;

查看是否开启半同步复制
mysql> show status like Rpl_semi_sync_master_status;
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| Rpl_semi_sync_master_status | ON    |
+-----------------------------+-------+

mysql> show status like Rpl_semi_sync_slave_status;
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Rpl_semi_sync_slave_status | ON    |
+----------------------------+-------+

配置文件
#plugin_load = "rpl_semi_sync_master=semisync_master.so;rpl_semi_sync_slave=semisync_slave.so"
rpl_semi_sync_slave_enabled = 1
rpl_semi_sync_master_enabled = 1
rpl_semi_sync_master_wait_point = after_sync
rpl_semi_sync_master_timeout =10000
rpl_semi_sync_master_wait_no_slave=0

依然没有得到解决

复盘结论

主库最后一个事务truncate操作没有同步到从库。

主库异常宕机挂掉，truncate没有同步到从库，而当主库重启，被作为新从库，重新加入到主从中去的时候，由于该表数据已经被truncate掉，新主中对该表数据的update

操作同步过来的时候就会报错1032，找不到要更新的数据，主从异常。为了避免主从不一致，尝试改为增强半同步，依然没有解决该问题。

主从不一致分析

主从复制

master事务的提交不需要经过slave的确认，slave是否接收到master的binlog，master并不care。slave接收到master

binlog后先写relay log，最后异步地去执行relay log中的sql应用到自身。由于master的提交不需要确保slave

relay log是否被正确接受，当slave接受master binlog失败或者relay log应用失败，master无法感知。

真实案例：主备切换数据不一致分析_binlog_11

异步复制本身对于数据一致性不做保证

半同步复制

基于传统异步存在的缺陷，mysql在5.7版本推出增强半同步复制。可以说半同步复制是传统异步复制的改进，在master事务的commit之前，必须确保一个slave收到relay

log并且响应给master后（从库收到并产生 relaylog 后会向主库发送一个 ACK 的信息包，当主库获得这个包后，认为从库已经获得 relaylog）才能进行事务的commit。但是slave对于relay log的应用仍然是异步进行的。

真实案例：主备切换数据不一致分析_半同步_12

AFTER_COMMIT 方式

MYSQL5.7 之前半同步复制采用的是 AFTER_COMMIT 方式--比 AFTER_SYNC 会有更大概率造成数据不一致

AFTER_COMMIT 是先做 REDO COMMIT 后传 BINLOG，做事务提交，只是不给客户端返回。

AFTER_COMMIT（5.6默认值）

master将每个事务写入binlog ,传递到slave 刷新到磁盘(relay log)，同时主库提交事务。

master等待slave 反馈收到relay log，只有收到ACK后master才将commit OK结果反馈给

客户端。

实际上，主库在等待ACK的InnoDB存储引擎内部已经提交事务，

只是阻塞了返回给发起事务提交的客户端消息而已。该缺陷可能导致非发起数据提交的客户端在碰到主库故障转移时发生幻读。

真实案例：主备切换数据不一致分析_binlog_13

commitTrx的调用在engine层commit之后（在ordered_commit函数中process_after_commit_stage_queue调用），如上图所示。即在等待Slave

ACK时候，虽然没有返回当前客户端，但事务已经提交，其他客户端会读取到已提交事务。如果Slave端还没有读到该事务的events，同时主库发生了crash，然后切换到备库。那么之前读到的事务就不见了，出现了幻读。

测试：

从库上停掉IO_THREAD模拟从库异常
stop replica io_thread;

主库上插入一条数据，此时会HANG住（但是这条数据已经写入了，开启一个会话是可以查到该数据的）
insert into t1 values(3);
开启新SESSION查询T表
select * from t1;
返回1，2，3
开启另一个会话杀掉主库MYSQLD进程pkill -9 mysqld
此时从库中是查不到插入3这条数据的。

select * from t;
返回1,2

如果此时发生主从切换则主从数据发生不一致。这也是after_commit模式复制中幻读现象。如图：

真实案例：主备切换数据不一致分析_binlog_14

AFTER_SYNC方式

AFTER_SYNC 是先传 binlog 后做 REDO COMMITmaster 将每个事务写入binlog , 传递到slave 刷新到磁盘(relay log)。master

等待slave 反馈接收到relay log的ack之后，再提交事务并且返回commit OK

结果给客户端。

即使主库crash，所有在主库上已经提交的事务都能保证

已经同步到slave的relay log中。

sync_binlog对主备的影响

参数值含义

sync_binlog= 0/1/n
0：表示每次提交事务都只 write，不 fsync，每过一秒fsync到磁盘，每一秒刷一次磁盘
1：表示每次事务提交都刷一次磁盘，也就是每次提交事务都会执行fsync
n：（100 200 500）表示每次提交事务都 write到OS cache，但累积 N 个事务后才 fsync到磁盘