没有使用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

ITPub博客

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

1032 ---master 与slave表或者数据不一致

最新文章