51php 数据不同步,故障案例：高可用切换后数据不一致，旧主库数据丢失

故障现象：

有台物理机宕机，复制架构是master-master+半同步，期间触发了高可用容灾切换，后台显示成功切换到了备库。但是等旧主库起来后，主从状态正常，但是旧主库上却丢失了一部分数据，通过对比发现这些数据都是在宕机瞬间的写操作

原因分析：

1 假设旧主库A丢失的数据记录为X，我们去A上解析发现宕机那段时间并无X记录的binlog信息，可确定在宕机瞬间该记录X没有binlog落盘；

2 因为我们开了log_slave_updates,我们去新主库B上解析那段时间的binlog，发现存在binlog记录，并且server-id是A的，可确定这个X记录是旧主库A传给新主库B的，而不是B自己产生的

3 初步猜测，宕机瞬间旧主库A部分binlog没有落盘，但是却已经传到了新主库B，等旧主库通过redo异常恢复时，因为binlog中无X记录的操作，则直接回滚了该操作，导致A上无X记录，而X记录已经存在备库B的binlog中并成功执行，导致双主两边数据不一致

3 那么主要需要排查的就是：为什么主库binlog没有落盘的情况下，能否直接传给从库？

4 通过查看参数设置，发现A上将sync_binlog设置为0，即binlog落盘时间完全由操作系统决定，而不是每次操作都会将binlog落盘，这样旧主库A在宕机时就可能丢失部分binlog；

MYSQL_BIN_LOG::sync_binlog_file(bool force)

{

bool synced= false;

unsigned int sync_period= get_sync_period();//获取sync_binlog参数值

if (force || (sync_period && ++sync_counter >= sync_period))

{

sync_counter= 0;

binlog写文件的情况

1 强制写

2 sync_binlog>=1且binlog写入次数>=sync_binlog数值

3 操作系统决定

而从库去主库读取binlog时，并不一定要等到binlog落盘，而是直接从pagecache中读取；这也就可能产生这个现象：

线程1写文件，还没fsync；

线程2读文件，直接从pagecache中读取成功；

主库宕机，fsync失败

通过查看源码发现，代码已经给出了解释：sync_binlog为1的情况下可保证在主库binlog落盘前，事件不会先被dump线程取走

need_LOCK_log= (get_sync_period() == 1);

/LOCK_log is not released when sync_binlog is 1. It guarantees that the

events are not be replicated by dump threads before they are synced to disk./

if (change_stage(thd, Stage_manager::SYNC_STAGE, wait_queue,

need_LOCK_log ? NULL : &LOCK_log, &LOCK_sync))

{

DBUG_PRINT("return", ("Thread ID: %lu, commit_error: %d",

thd->thread_id, thd->commit_error));

DBUG_RETURN(finish_commit(thd));

}

final_queue= stage_manager.fetch_queue_for(Stage_manager::SYNC_STAGE);

线程读取和写文件的方式并没有改变，所以mysql在内部使用了锁来控制时序性，在binlog落盘前加锁，阻塞线程2读取文件，直到线程1 fsync完成后才释放，这样在sync_binlog=1的情况下就可以简单理解成串行先执行binlog落盘完成后再被dump线程读取了。

解决方法

1 人工修复这部分数据，数量多的话重做主从

2 将sync_binlog改为1，杜绝这个情况再次发生