沒有使用GTID的主備

1032 ---master 與slave表或者資料不一致

第一種情況（salve不存在該表）：master DML等操作，slave報錯 ---直接sql-slave-skip-counter即可，同步後，再補上這張表及資料

第二中情況（slave存在該表，但資料缺失）：master update/delete操作，slave報錯 ---丟失的補齊再進行 sql-slave-skip-counter即可/delete不需要補直接skip吧，畢竟補了也會刪除

1062 ---主鍵重複 （insert） ---刪除主鍵再同步

----其實上面三種情況都可以直接sql-slave-skip-counter這樣解決，但可能造成資料的不一致情況

原因：

1 Replication 時使用了主--binlog-do-db=db_name或者從--replicate_do_db=db_name.
假設有兩個庫 pubs 和 test,忽略的是test,
--binlog-do-db=test
--replicate_do_db=push.
結果有這樣一條sql 在主上的test庫執行:insert into pubs.tname values(XXXXX); ---這條語句影響的是push庫，本應該記錄在日誌中的，但是卻是在test庫上執行的，又被忽略了，後期再push庫上對該條資料進行操作從庫就報錯說找不到啦等等。。。。
那麼根據服務的配置,主上執行成功,從上沒有執行,就會引發1032錯誤

補充方法：

slave_exec_mode

Command-Line Format	--slave-exec-mode=mode
System Variable	Name	slave_exec_mode
	Variable Scope	Global
	Dynamic Variable	Yes
Permitted Values	Type	enumeration
	Default	STRICT (ALL)
	Default	IDEMPOTENT (NDB)
	Valid Values	IDEMPOTENT
		STRICT

補充的方法：
http://blog.itpub.net/29096438/viewspace-1826758/

還可以使用pt-slave-restart工具進行修復
http://blog.itpub.net/29254281/viewspace-1183545/

使用GTID的新特新後
當備庫複製出錯時，傳統的跳過錯誤的方法是stop slave設定sql_slave_skip_counter,然後再START SLAVE。

英文原版的解決辦法

（英文地址https://www.percona.com/blog/2013/03/26/repair-mysql-5-6-gtid-replication-by-injecting-empty-transactions/）
我們檢視一下發現
Last_SQL_Error: Error 'Duplicate entry '4' for key 'PRIMARY'' on query. Default database: 'test'. Query: 'insert into t VALUES(NULL,'salazar')'
Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5 已經接收到5了
Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-4 但只執行到4，所以錯誤就出在5中
STOP SLAVE;
SET GTID_NEXT="7d72f9b4-8577-11e2-a3d7-080027635ef5:5";
BEGIN; COMMIT;
SET GTID_NEXT="AUTOMATIC";
START SLAVE;
[...]
Retrieved_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5
Executed_Gtid_Set: 7d72f9b4-8577-11e2-a3d7-080027635ef5:1-5

網上一些其它方法：
http://blog.csdn.net/magerguo/article/details/9145329

【Mysql】Slave_SQL_Running: No：Last_Error: Error ：1032/1062

1032 ---master 與slave表或者資料不一致

相關文章