今天星期二，早上居然起晚了，上班遲到了，簡直是。。。廢話不多說，在昨天的文章中，我們提到了三個參數(shù)，分別是：

slave_exec_mode參數(shù)； sql_slave_skip_counter=N參數(shù); slave-skip-errors=N參數(shù)。

這三個參數(shù)都可以解決并行復制中的一些指定的錯誤，例如duplicate key 1062錯誤等，今天我們簡單試驗一下，這三個參數(shù)的區(qū)別：

01 sql_slave_skip_counter參數(shù)

這個參數(shù)的設置主要是為了跳過某些錯誤的'event',注意這里的用詞是event而不是事務，是因為它的本質是跳過一個一個事件，需要注意的是，這個參數(shù)需要在偏移量復制模式中使用，如果使用的是gtid的復制模式，則不可以使用這個參數(shù)。我們來看例子，首先搭建一套復制關系：

master 10.30.124.68

slave 10.30.124.128

這倆實例互為主從。我們創(chuàng)建測試表test.yeyz，并插入一些數(shù)據(jù)，其中id為主鍵，具有唯一性，如下：

master上

mysql:(none) 22:25:56>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 |+----+------+4 rows in set (0.00 sec)

slave上

mysql:(none) 22:25:38>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 |+----+------+5 rows in set (0.00 sec)

我們可以發(fā)現(xiàn)，從節(jié)點的數(shù)據(jù)比主節(jié)點多一條，多了id=5的記錄，然后我們在主節(jié)點上插入數(shù)據(jù)：

mysql:(none) 22:26:06>>insert into test.yeyz values (5,5),(6,6);Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0

此時觀察從節(jié)點：

mysql:(none) 22:26:34>>show slave statusG Master_Host: 10.30.124.68 Master_User: dba_repl Master_Port: 4306Connect_Retry: 60 Master_Log_File: mysqlbin.000002 Read_Master_Log_Pos: 523 Relay_Log_File: slave-relay-bin.000002Relay_Log_Pos: 319Relay_Master_Log_File: mysqlbin.000002 Slave_IO_Running: Yes Slave_SQL_Running: No Last_Errno: 1062 Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction ’ANONYMOUS’ at master log mysqlbin.000002, end_log_pos 492. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any. Skip_Counter: 0

可以發(fā)現(xiàn)，從節(jié)點已經SQL線程斷開了， 這個時候，在主節(jié)點上查詢這個錯誤position 492處的binlog，可以看到：

mysql:(none) 22:30:28>>show binlog events in ’mysqlbin.000002’ from 194; +-----------------+-----+----------------+-----------+-------------+--------------------------------------------+| Log_name| Pos | Event_type | Server_id | End_log_pos | Info |+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+| mysqlbin.000002 | 194 | Anonymous_Gtid | 192 | 259 | SET @@SESSION.GTID_NEXT= ’ANONYMOUS’ || mysqlbin.000002 | 259 | Query | 192 | 327 | BEGIN || mysqlbin.000002 | 327 | Rows_query | 192 | 391 | # insert into test.yeyz values (5,5),(6,6) || mysqlbin.000002 | 391 | Table_map | 192 | 439 | table_id: 108 (test.yeyz) || mysqlbin.000002 | 439 | Write_rows | 192 | 492 | table_id: 108 flags: STMT_END_F || mysqlbin.000002 | 492 | Xid | 192 | 523 | COMMIT /* xid=38 */|+-----------------+-----+----------------+-----------+-------------+--------------------------------------------+6 rows in set (0.00 sec)

從上面的binlog可以看出來，我們的一個insert操作實際上生成了5個enent，分別對應的pos是從259~492，關于event，待會兒再說。

因為主節(jié)點上插入了id=5的記錄，跟從節(jié)點上的記錄沖突了，查看錯誤日志，可以發(fā)現(xiàn)：

Duplicate entry ’5’ for key ’PRIMARY’, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event’s master log FIRST, end_log_pos 492 | 2019-07-16 22:26:25

我們通過sql_slave_skip_counter參數(shù)的設置來解決這個問題，步驟如下：

mysql:(none) 22:29:32>>stop slave;Query OK, 0 rows affected, 1 warning (0.00 sec)mysql:(none) 22:32:45>>set global sql_slave_skip_counter=1;Query OK, 0 rows affected (0.00 sec)mysql:(none) 22:33:06>>start slave;

在昨天的文章中我們說過，sql_slave_skip_counter后面跟的值是event的個數(shù)，所以這里我們相當于跳過了一個event，mysql中規(guī)定，如果跳過一個event之后，還在某一個事務里面，那么會繼續(xù)跳過這個事務。

使用這個參數(shù)跳過一個event之后，我們再來看從庫表中的數(shù)據(jù)和復制情況，可以看到：

slave表：

mysql:(none) 22:33:10>>show slave statusG*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.30.124.68 Master_User: dba_repl Master_Port: 4306Connect_Retry: 60 Master_Log_File: mysqlbin.000002 Read_Master_Log_Pos: 523 Relay_Log_File: slave-relay-bin.000003Relay_Log_Pos: 319Relay_Master_Log_File: mysqlbin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yesmysql:(none) 22:33:16>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 |+----+------+5 rows in set (0.00 sec)

看看master表：

mysql:(none) 22:33:36>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 |+----+------+6 rows in set (0.00 sec)

可以發(fā)現(xiàn)，master中數(shù)據(jù)插入成功，而slave中數(shù)據(jù)插入失敗，也就是說：

該參數(shù)跳過錯誤的時候，會導致主從的數(shù)據(jù)不一致。

02 slave_skip_errors參數(shù)

這個參數(shù)是跳過制定的錯誤，也就是說，需要我們設置對應的error_code，從下面的日志中的內容可以看出，error_code的值為1062

Duplicate entry ’5’ for key ’PRIMARY’, Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event’s master log FIRST, end_log_pos 492 | 2019-07-16 22:26:25

我們需要手動將這個參數(shù)的值也該為1062，需要注意的是，這個參數(shù)的改動需要重啟mysql服務，因為這個參數(shù)是一個只讀的參數(shù)。

修改后的情況如下：

mysql--dba_admin@127.0.0.1:(none) 22:38:55>>show variables like ’%errors%’;+--------------------+---------+| Variable_name | Value |+--------------------+---------+| max_connect_errors | 1000000 || slave_skip_errors | 1062 |+--------------------+---------+2 rows in set (0.01 sec)

此時我們更新master表和slave表的數(shù)據(jù)，更新后的情況如下：

master：

mysql:(none) 22:39:15>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 |+----+------+6 rows in set (0.00 sec)

slave上：

mysql:(none) 22:40:15>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 || 7 | 7 |+----+------+7 rows in set (0.00 sec)

我們發(fā)現(xiàn)，slave表比master表多一條數(shù)據(jù)，也就是id=7的記錄，此時我們在master上執(zhí)行：

mysql:(none) 22:34:15>>insert into test.yeyz values (7,7),(8,8);Query OK, 2 rows affected (0.00 sec)Records: 2 Duplicates: 0 Warnings: 0

查看slave上面的復制情況和數(shù)據(jù)情況，如下：

mysql:(none) 22:39:05>>show slave statusG*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.30.124.68 Master_User: dba_repl Master_Port: 4306Connect_Retry: 60 Master_Log_File: mysqlbin.000002 Read_Master_Log_Pos: 852 Relay_Log_File: slave-relay-bin.000005Relay_Log_Pos: 648Relay_Master_Log_File: mysqlbin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table:Replicate_Ignore_Table: Replicate_Wild_Do_Table: mysql:(none) 22:40:15>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 || 7 | 7 |+----+------+7 rows in set (0.00 sec)

可以看到，復制沒有出現(xiàn)錯誤，即使從庫上已經有id=7的記錄。而且發(fā)現(xiàn)，從庫的數(shù)據(jù)跟之前保持一致，也就是說，主庫插入的id=8的記錄沒有被同步過來。

總結一下：該參數(shù)在跳過復制錯誤的時候，需要重啟mysql服務，然后可能導致主從數(shù)據(jù)不一致。

03 slave-skip-errors=N參數(shù)

再看最后一個參數(shù)，這個參數(shù)表示的是并行復制過程中的從庫復制模式，默認值是strict嚴格模式，和上面一樣，我們先看主庫和從庫的數(shù)據(jù)情況：

master數(shù)據(jù)：

mysql:(none) 22:39:20>>select * from test.yeyz; +----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 || 7 | 7 || 8 | 8 |+----+------+8 rows in set (0.00 sec)

slave數(shù)據(jù)：

mysql:(none) 22:42:46>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 || 7 | 7 || 8 | 8 || 9 | 9 |+----+------+9 rows in set (0.00 sec)

此時我們在從庫上修改參數(shù)如下：

mysql:(none) 22:42:59>>show variables like ’%exec%’;+----------------------------------+--------+| Variable_name | Value |+----------------------------------+--------+| gtid_executed_compression_period | 1000 || max_execution_time | 0 || rbr_exec_mode | STRICT || slave_exec_mode | STRICT |+----------------------------------+--------+4 rows in set (0.00 sec)mysql:(none) 22:44:05>>set global slave_exec_mode=’IDEMPOTENT’;Query OK, 0 rows affected (0.00 sec)mysql:(none) 22:44:10>>show variables like ’%exec%’; +----------------------------------+------------+| Variable_name | Value |+----------------------------------+------------+| gtid_executed_compression_period | 1000 || max_execution_time | 0 || rbr_exec_mode | STRICT || slave_exec_mode | IDEMPOTENT |+----------------------------------+------------+4 rows in set (0.00 sec)

修改完參數(shù)，我們在主庫上進行insert操作：

insert into test.yeyz values (9,9),(10,10);

查看從庫的復制狀態(tài)和數(shù)據(jù)情況，如下：

mysql:(none) 22:44:14>>show slave statusG*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 10.30.124.68 Master_User: dba_repl Master_Port: 4306Connect_Retry: 60 Master_Log_File: mysqlbin.000002 Read_Master_Log_Pos: 1183 Relay_Log_File: slave-relay-bin.000007Relay_Log_Pos: 650Relay_Master_Log_File: mysqlbin.000002 Slave_IO_Running: Yes Slave_SQL_Running: Yes1 row in set (0.00 sec)mysql:(none) 22:44:38>>select * from test.yeyz;+----+------+| id | age |+----+------+| 1 | 1 || 2 | 2 || 3 | 3 || 4 | 4 || 5 | 5 || 6 | 6 || 7 | 7 || 8 | 8 || 9 | 9 || 10 | 10 |+----+------+10 rows in set (0.00 sec)

可以發(fā)現(xiàn)，既沒有出現(xiàn)復制錯誤，主庫上插入的數(shù)據(jù)也同步過來了。

總結一下： slave_exec_mode參數(shù)； sql_slave_skip_counter=N參數(shù); slave-skip-errors=N參數(shù)。

這三個參數(shù)都能解決復制過程中的不一致情況，區(qū)別如下：

slave_exec_mode參數(shù)可以保證主從數(shù)據(jù)一致，其他兩個不可以。

slave-skip-errors參數(shù)可以跳過制定的錯誤，但是需要重啟實例，不能保證數(shù)據(jù)一致。

sql_slave_skip_counter參數(shù)需要在偏移量的復制模式下使用，不能保證數(shù)據(jù)一致。

以上就是MySQL復制問題的三個參數(shù)分析的詳細內容，更多關于MySQL復制問題的資料請關注好吧啦網(wǎng)其它相關文章！