MySQL将跳过1032 1062错误
传统复制
slave _ exec _ mode (全局级别) IDEMPOTENT or STRICT
controlshowaslavethreadresolvesconflictsanderrorsduringreplication.idempotentmodecausessuppressionofduplicate-keyandno
idempotentmodeisintendedforuseinmulti-master复制，circular复制， andsomeotherspecialreplicationscenariosforndbclusterreplication.(see section 21.6.10，“ndb群集复制： multi and Section 21.6.11，“ndbclusterreplicationconflictreection”for more information.) ndbclusterignoresanyvaluexplicitlystion
In MySQL Server 5.7，严格模式is the default value。
or storage engines other than NDB， idempotentmodeshouldbeusedonlywhenyouareabsolutelysurethatduplicate-keyerrorsandkey-not-founderrorscansafelybeignored. obeusedinfail-overscenariosforndbclusterwheremulti-masterreplicationorcircularreplicationisemployed，andisnotrecomecomended
对于IDEMPOTENT (幂模式) (一个事务中有三个SQL，中间SQL语句是严格的)模式下出现1062或1032错误) ) )。
此参数对传统复制和GTID复制都有相同的效果
对于1062主键冲突错误，无论kfdgslog_format是ROW格式还是STATEMENT格式，从主库中同步的数据都会复盖库中发生主键冲突的行的值。 也就是说，它被视为正在从库中执行replace操作。
对于在第1032行中找不到的错误，无论kfdgslog_format是ROW格式还是STATEMENT格式，库本地都会忽略此SQL语句，并且不会执行。 只需执行事务中没有其他错误的SQL。
SQL_slave_skip_counter (全局级别)
此参数仅对传统复制有效，GTID复制只能使用gtid_next。
如果kfdgslog_format为ROW格式，则发生1032或1062，表中将自增强作为主键存在，在master上执行插入操作时未指定主键。 在这种情况下，需要注意主键的键值信息，在发生1032或1062错误而跳过后，master和slave很可能被跳过，因此应该注意的操作是delete、insert、truncate。
参数的对象单位是statment还是row。 对于语句，在一个事务中运行多个语句时，可能会出现以下三种错误： 1032或1062？
整个事务将被跳过而不执行，并且已经在此语句之前执行的那些也将回滚。
但是，跳过报告错误的语句，如果后面有语句，则继续运行。
将跳过报告错误的语句和所有后续尚未运行的语句，但不会回滚之前成功运行的语句。
如果kfdgslog_format格式为ROW格式，且sql_slave_skip_counter=1为1032或1062，则跳过整个事务。
如果kfdgslog_format的格式为statement，则sql_slave_skip_counter=1时出现1062个错误，将跳过整个事务。
如果kfdgsglog_format的格式为statement，则针对1032个错误，修复了整个事务中存在一个主库存，但不存在从库存
row的数据的时候，在从库是不会报错的，并且这事务的其他语句是可以成功执行的。slave_skip_errors(global级别) 这个参数暂时还是只读参数，不能动态修改，要想修改的话必须在配置文件里面修改并且重启数据库实例才会生效。
这个参数针对gtid和传统复制有效，并且俩者的结果都一样。报错的SQL语句会跳过，但是其余的SQL还是正常执行。
设置slave_skip_errors=1062或者1032在kfdgslog_format是statement的情况下，整个事务只会跳过报1062或者1032错误的sql，不执行这条SQL，其余的sql正常进行。
设置slave_skip_errors=1062或者1032在kfdgslog_format是ROW的情况下，整个事务只会跳过报1062或者1032错误的sql，不执行这条SQL其余的sql正常进行。
总结：
GTID复制
gtid_next(session级别)
GTID模式的下
在master获取GTID执行的信息：
mysql> show master status;
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------+
| mysql-kfdgs.000026 | 4347 | | | 834f1e16-fa69-11e7-b271-000c291f2799:1-1013108,
b7737e22-e469-11e7-b6b9-000c29a80f41:1-94000 |
+------------------+----------+--------------+------------------+----------------------------------------------------------------------------------------------+
在slave获取未执行GTID信息:主要是观察Retrieved_Gtid_Set和Executed_Gtid_Set的值
mysql> show slave status G
......
Replicate_Ignore_Server_Ids:
Master_Server_Id: 73306
Master_UUID: 834f1e16-fa69-11e7-b271-000c291f2799
Master_Info_File: mysql.slave_master_info
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: 834f1e16-fa69-11e7-b271-000c291f2799:1013102-1013108
Executed_Gtid_Set: 069020a4-d346-11e7-a9e6-000c2920ceb4:1-123487,
69d937df-dbfe-11e7-84e5-000c291f2799:1-2,
834f1e16-fa69-11e7-b271-000c291f2799:1-1013107,
b7737e22-e469-11e7-b6b9-000c29a80f41:1-94000,
f1542f99-0015-11e8-a7c3-000c29a80f41:1-6
Auto_Position: 1
Replicate_Rewrite_DB:
Channel_Name:
Master_TLS_Version:
......
在slave设置空的gtid值
root@mysqldb 16:12: [percona]> show variables like '%next%';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| gtid_next | AUTOMATIC |
+---------------+-----------+
1 row in set (0.00 sec)
root@mysqldb 16:14: [percona]> set gtid_next='834f1e16-fa69-11e7-b271-000c291f2799:1013108';
Query OK, 0 rows affected (0.00 sec)
root@mysqldb 16:14: [percona]> begin;commit;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.02 sec)
root@mysqldb 16:14: [percona]> set gtid_next='AUTOMATIC';
Query OK, 0 rows affected (0.00 sec)
重启slave
20180612 补充
固定路数应该是从从库的报错信息中获取得到当前报错的schema,table,primary key定义到具体的row出现主键冲突，然后在slave上面删除这行数据，再重新启动slave的SQL_THREAD进程。