一次Mysql主从不一致故障解决

背景

1. Mysql主库binlog格式是row。
2. 在主库清除了几张表的所有数据，数据有百万条，并且有一张表没有主键也没有索引，导致从库主从同步卡住，延时不断增大（因为主库binlog是row格式，清表操作会把每条数据的删除sql写入binlog，并且没有主键也没有索引的表的删除记录操作，每次都需要全表扫描）。
3. 此情景下，在主库给该表添加了索引，在从库给该表添加了索引，在从库还执行了跳过同步事务等操作，导致不停的报主从同步错误。
4. 从库都是数据统计服务在用，已经把实时数据服务且到主库，但凌晨有很多定时任务要跑，所以要在几个小时内修复问题。

思路

1. 根据从库报错位置手动修复记录，后续再同步数据，但修复了多条数据后，依然报错，这个方案不可行，不知道需要手动修复多少数据，而且还需要后续同步数据。
2. 根据从库本地binlog回滚数据后再进行主从同步，没有找到合适的工具。
3. 在主库binlog中找到清表操作的最后位置，从该位置开始同步，手动在从库执行清表操作，但发现不同表的删除数据中间还夹杂着其他表的insert，update操作，这样重置从库的同步位置，开始同步后会报主键重复（1062），不能找到记录（1032）错误。

解决

1. 停止从库服务，修改从库配置文件：

vi /etc/my.cnf
[mysqld]
slave-skip-errors=1062,1032  #跳过指定error no类型的错误
#slave-skip-errors=all #跳过所有错误

2. 重置从库同步binlog位置，并启动从库
3. 重新启动主从同步
4. 待同步完成，停止从库服务，恢复配置文件，启动从库

命令

show slave status几个重要参数说明：

Slave_IO_Running: 接收master的binlog信息
Master_Log_File： 正在云读取master上binlog日志名
Read_master_Log_Pos: 正在读取master上当前的binlog日志POS点
slave_SQL_Running: 执行写操作
Relay_master_Log_File： 正在同步master上binlog日志名
Exec_master_log_Pos: 正在同步当前binlog日志的POS点

查看binlog内容

./mysqlbinlog -v --base64-output=DECODE-ROWS /data/mysql/data/mysql-bin.000004 | grep -A ‘10’ 3704

跳过指定数量的事务：

mysql>slave stop;
mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务
mysql>slave start;

参考：https://blog.csdn.net/anzhen0429/article/details/77113652