【20180205】MySQL 1032和1062跳過錯誤總結

MySQL跳過 1032 1062錯誤

傳統複製情況

1. 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。
2. 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的數據的時候，在從庫是不會報錯的，並且這事務的其他語句是可以成功執行的。

3. 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正常進行。
4. 總結：

GTID複製

1. 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值

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進程。