MySQL跳過 1032 1062錯誤
傳統複制情況
slave_exec_mode(global級别) IDEMPOTENT or STRICT
Controls how a slave thread resolves conflicts and errors during replication. IDEMPOTENT mode causes suppression of duplicate-key and no- key-found errors; STRICT means no such suppression takes place.
IDEMPOTENT mode is intended for use in multi-master replication, circular replication, and some other special replication scenarios for NDB Cluster Replication. (See Section 21.6.10, “NDB Cluster Replication: Multi-Master and Circular Replication”, and Section 21.6.11, “NDB Cluster Replication Conflict Resolution”, for more information.) NDB Cluster ignores any value explicitly set for slave_exec_mode, and always treats it as IDEMPOTENT.
In MySQL Server 5.7, STRICT mode is the default value.
or storage engines other than NDB, IDEMPOTENT mode should be used only when you are absolutely sure that duplicate-key errors and key-not-found errors can safely be ignored. It is meant to be used in fail-over scenarios for NDB Cluster where multi-master replication or circular replication is employed, and is not recommended for use in other cases.
在IDEMPOTENT(幂等)模式的情況下的情況(一個事務内部3個SQL，中間的SQL語句在嚴格(STRICT)的模式下面會發生1062或者1032錯誤)
這個參數針對傳統複制還是GTID複制的效果還是一樣的
針對1062主鍵沖突的錯誤，無論binlog_format是ROW格式還是STATEMENT格式，從庫發生主鍵沖突的行的值都會被主庫同步過來的資料給覆寫掉，即認為在從庫執行replace操作。
針對1032行找不到的錯誤，無論binlog_format是ROW格式還是STATEMENT格式，從庫本地都會忽略這條SQL語句，不執行，隻是執行事務的其他沒有錯誤的SQL。
sql_slave_skip_counter(global級别)
這個參數隻是針對傳統複制有效，針對GTID複制隻能使用gtid_next.
在binlog_format為ROW格式的情況下，在出現1032或者1062的情況下，并且table存在自增健為主鍵，并且在master上面執行insert操作的時候沒有指定主鍵，這個時候需要注意主鍵的鍵值資訊，很有可能在出現1032或者1062錯誤跳過之後master和slave倆者的主鍵下一個鍵值可能不一緻。是以需要注意的操作有delete,insert,truncate。
參數針對的機關是statment還是row。若是針對statement的話，那麼在一個事務内部執行多條statement的話，遇到1032或者1062這種錯誤的話是有沒有如下三種情況：
整個事務都會跳過不會執行，在這個statement前面已經執行的也會復原。
隻是會跳過報錯的那條statement，後續還有statement的話還會繼續執行。
會跳過報錯的那條statement和後續所有的還沒有執行的statement，但是前面已經執行成功的statement不會復原。
在binlog_format的格式是ROW格式的情況下面，無論是1032還是1062情況下設定sql_slave_skip_counter=1,它會将整個事務跳過去。
在binlog_format的格式是statement的情況下,sql_slave_skip_counter=1并且是1062的錯誤，它會将整個事務跳過去。
binglog_format的格式是statement的情況下，針對1032錯誤，在整個事務當中出現修改一個主庫存在，但是從庫不存在的row的資料的時候，在從庫是不會報錯的，并且這事務的其他語句是可以成功執行的。
slave_skip_errors(global級别) 這個參數暫時還是隻讀參數，不能動态修改，要想修改的話必須在配置檔案裡面修改并且重新開機資料庫執行個體才會生效。
這個參數針對gtid和傳統複制有效，并且倆者的結果都一樣。報錯的SQL語句會跳過，但是其餘的SQL還是正常執行。
設定slave_skip_errors=1062或者1032在binlog_format是statement的情況下，整個事務隻會跳過報1062或者1032錯誤的sql，不執行這條SQL，其餘的sql正常進行。
設定slave_skip_errors=1062或者1032在binlog_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-bin.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值
[email protected] 16:12: [percona]> show variables like '%next%';
+---------------+-----------+
| Variable_name | Value |
+---------------+-----------+
| gtid_next | AUTOMATIC |
+---------------+-----------+
1 row in set (0.00 sec)
[email protected] 16:14: [percona]> set gtid_next='834f1e16-fa69-11e7-b271-000c291f2799:1013108';
Query OK, 0 rows affected (0.00 sec)
[email protected] 16:14: [percona]> begin;commit;
Query OK, 0 rows affected (0.01 sec)
Query OK, 0 rows affected (0.02 sec)
[email protected] 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程序。