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