1032错误码说明：
MySQL主从同步的1032错误，一般是指要更改的数据不存在，SQL_THREAD提取的日志无法应用故报错，造成同步失败
（Update、Delete、Insert一条已经delete的数据）。
1032的错误本身对数据一致性没什么影响，影响最大的是造成了同步失败、同步停止。
如果主主（主从）有同步失败，要第一时间查看并着手解决。因为不同步，会造成读取数据的不一致。应在第一时间恢复同步，
尽量减少对业务的影响。然后再具体分析不同步的原因，手动或者自动修复数据，并做pt-table-checksum数据一致性检查。
报错信息如下：
Slave_SQL_Running: NO Last_SQL_Errno: 1032 Last_SQL_Error: Worker 3 failed executing transaction '' at master log mysql-bin.000003, end_log_pos 440267874; Could not execute Delete_rows event on table db_test.tbuservcbgolog; Can't find record in 'tbuservcbgolog', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.000003, end_log_pos 440267874
从上可以看出，是SQL_THREAD线程出错，错误号码1032。是在应用delete db_test.tbuservcbgolog 表中一行数据的事件时，由于这条数据
不存在而出错。此事件在主服务器Master binlog中的位置是 mysql-bin.000003, end_log_pos 440267874。（当然可以在从服务器Slave的Relay
log中查找，具体方法见最后）
方法1：跳过错误Event
先跳过这一条错误(event),让主从同步恢复正常。（或者N条event，一条一条跳过）
stop slave;
set global sql_slave_skip_counter=1;
start slave;
参考连接 https://blog.csdn.net/wll_1017/article/details/70332107
执行上面命令会报错
mysql> set global sql_slave_skip_counter=1;
ERROR 1858 (HY000): sql_slave_skip_counter can not be set when the server is running with @@GLOBAL.GTID_MODE = ON. Instead, for each transaction that you want to skip, generate an empty transaction with the same GTID as the transaction
解决问题过程：
分析出现问题时候GTID值
通过分析法获取gtid值
通过查看mysql> show slave status G;
查看一下信息并记录下来:
Retrieved_Gtid_Set: 8f9e146f-0a18-11e7-810a-0050568833c8:1-4 --跳过此事务
Executed_Gtid_Set: 8f9e146f-0a18-11e7-810a-0050568833c8:1-3
通过上面的信息可以知道已经执行的gtid是8f9e146f-0a18-11e7-810a-0050568833c8:1-3,准备要执行8f9e146f-0a18-11e7-810a-0050568833c8:4的时候出问题了，所以条跳过此步骤
解决方法一：重置master方法跳过错误
mysql> STOP SLAVE;
mysql> RESET MASTER;
mysql> SET @@GLOBAL.GTID_PURGED ='8f9e146f-0a18-11e7-810a-0050568833c8:1-4'
mysql> START SLAVE;
解决方法二：使用pt-slave-restart工具
pt-slave-restart工具的作用是监视某些特定的复制错误，然后忽略，并且再次启动SLAVE进程（Watch and restart MySQL replication after errors）。
忽略所有1062错误，并再次启动SLAVE进程
[root@dgt mysql]# pt-slave-resetart -S /var/lib/mysql/mysql.sock —error-numbers=1062
检查到错误信息只要包含 test.t1，就一概忽略，并再次启动 SLAVE 进程
[root@dgt mysql]# pt-slave-resetart -S /var/lib/mysql/mysql.sock —error-text=”test.t1”
方法2：跳过所有1032错误
更改my.cnf文件，在Replication settings下添加：
slave-skip-errors ＝ 1032
并重启数据库，然后start salve。
注意：因为要重启数据库，不推荐，除非错误事件太多。
方法3：还原被删除的数据
根据错误提示信息，用mysqlbinlog找到该条数据event SQL并逆向手动执行。如delete 改成insert。
本例中，此事件在主服务器Master binlog中的位置是 mysql-bin.000003, end_log_pos 440267874。
1）利用mysqlbinlog工具找出440267874的事件
/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 |grep -A 20 '440267874'
或者/usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 --stop-position=440267874 | tail -20
或者usr/local/mysql-5.6.30/bin/mysqlbinlog --base64-output=decode-rows -vv mysql-bin.000003 > decode.log
（ 或者加上参数-d, --database=name 来进一步过滤）
#160923 20:01:27 server id 1223307 end_log_pos 440267874 CRC32 0x134b2cbc Delete_rows: table id 319 flags: STMT_END_F ### DELETE FROM `db_99ducj`.`tbuservcbgolog` ### WHERE ### @1=10561502 /* INT meta=0 nullable=0 is_null=0 */ ### @2=1683955 /* INT meta=0 nullable=0 is_null=0 */ ### @3=90003 /* INT meta=0 nullable=0 is_null=0 */ ### @4=0 /* INT meta=0 nullable=0 is_null=0 */ ### @5='2016-09-23 17:02:24' /* DATETIME(0) meta=0 nullable=1 is_null=0 */ ### @6=NULL /* DATETIME(0) meta=0 nullable=1 is_null=1 */ # at 440267874
以上为检索出来的结果，事务语句为：delete from db_99ducj.tbuservcbgolog where @1=10561502 and @2=1683955 ...
其中@1 @2 @3...分别对应表tbuservcbgolog的列名，填补上即可。
我们可以逆向此SQL 将deleter 变成Insert,手动在从库上执行此Insert SQL,之后restart slave就好了。
注：通过Relay Log查找event SQL http://www.tuicool.com/articles/6RvUnqV