虽然MySQL5.7 的主从复制已经很稳定了，但在备库可读写的情况下，总是会出现部分数据不一致的情况，例如常见的1062、1032和1050错误。下面就介绍下这类报错的常见处理方法和常见主从复制结构的调整。
1、mysql 5.7 以上，
2、binlog format 是row格式（5.7默认）
3、传统复制（生产强烈推荐使用gtid）
4、log-bin , log_slave_updates 开启
5、复制结构：101：3306> 103:3306 > 104:3306
1、表重复错误： 1050
从库已经有T2表，再在主库上创建T2. 处理原则：以主库为准，在从库上drop t2。 然后重启slave。
注意： 在db里的操作都会记录到binlog中，如果不想被记录到binlog中，可以先set sql_log_bin=0.drop完成后，再 set sql_log_bin=1即可。
从5.7 开始，有super read only。
处理方法：
从库操作：
set sql_log_bin=0；
drop table t2;
set sql_log_bin=1;
start slave;
show slave status;
2、主键冲突： 1062
处理方法：
从库操作：
set sql_log_bin=0；
delete from t2 where id =2;
set sql_log_bin=1;
start slave;
show slave status;
3、主库上更新后，从库找不到记录 ：1032
这时需要解析主库的binlog，把从库的数据补回来。
这里就能看到从库丢失的那条记录。然后在从库补充这条记录即可。
处理方法：
从库操作：
set sql_log_bin=0；
insert into t2 (id) values (2);
set sql_log_bin=1;
start slave;
show slave status;
4、主库上delete后，从库找不到记录： 1032
想看某段pos内执行过的sql： 主库执行：
mysqlbinlog --base64-output=decode-rows -v --start-position=2465
--stop-position=2748 mysql-bin.000050 > 50.sql
输出如下：
### DELETE FROM `wubx`.`wubx` ### WHERE ### @1=2### @2='wubx'
ROLLBACK /* added by mysqlbinlog */ /*!*/;
注意这里的rollback。如果以后基于binlog和时间点的恢复。这条数据会被rollback掉，造成一条数据的丢失。所以如果想保留这条数据，需要找到commit的位置，或者下个pos的位置。
处理方法：
从库操作：
slave stop;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #跳过一个事务
slave start
1、一主一从，添加从库
st=>operation: M 101:3306 e=>end op=>operation: S1 103:3306 st->op->op1
调整为，级联或星型结构
st=>operation: M 101:3306 e=>end op=>operation: S1 103:3306 op1=>operation: S11 104:3306 st->op->op1
2、级联复制调整
从103.3306 dump数据
mysqldump --single-transaction --master-data=2 -uroot -p123456 -A -S
/tmp/mysql3306.sock
104 导入数据
mysql -S /tmp/mysql3306.sock -uroot -p123456 < /tmp/1203.sql
change 104 到103
change master to master_host='192.168.56.103', master_user='repl',
master_password='repl4slave', master_port=3306,
MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=4138,
master_connect_retry=10;
101 插入测试数据
insert into t2 values (200);
101 持续insert
for ((i=1;i<=1000000;i++))
do
mysql -S /tmp/mysql3306.sock -uroot -p123456 -e
"insert into enmo.t2 values($i)"done关闭103 主机，并检查104 slave 状态
主从的binlog 都会记录主库的server id 和timestamp信息。可以根据这2个信息去定位相应的pos信息。
101:3306
104:3306
这里可以看到101 结束 insert 1419后，并commit的 pos 是387204，所以104 change 的pos 可以选择到387204这里。但是如果104没有把1419 这条记录commit的话，就要选择101 开始 insert 1419 这个事务之间的pos：387020.
104 change 到101
change master to master_host='192.168.56.103',
master_user='repl', master_password='repl4slave',
master_port=3306, MASTER_LOG_FILE='mysql-bin.000093',
MASTER_LOG_POS=387204, master_connect_retry=10;
作者介绍
张灿 云和恩墨技术顾问
2015年12月加入云和恩墨，擅长oracle、mysql数据库，shell、python脚本。
关注本公众号，回复：prelection，你可以找到本文的相关视频文档。
相关阅读：
揭秘：Instapaper基于AWS上MySQL历时一周的恢复
资源下载
关注公众号：数据和云（OraNews）回复关键字获取
‘2017DTC’，2017DTC大会PPT
‘DBALIFE’，“DBA的一天”海报
‘DBA04’，DBA手记4经典篇章电子书
‘RACV1’, RAC系列课程视频及ppt
‘122ARCH’，Oracle 12.2体系结构图
‘2017OOW’，Oracle OpenWorld资料
‘PRELECTION’，大讲堂讲师课程资料