MySQL復(fù)制問(wèn)題的三個(gè)參數(shù)分析
今天星期二，早上居然起晚了，上班遲到了，簡(jiǎn)直是。。。廢話不多說(shuō)，在昨天的文章中，我們提到了三個(gè)參數(shù)，分別是：
- slave_exec_mode參數(shù)；
- sql_slave_skip_counter=N參數(shù);
- slave-skip-errors=N參數(shù)。
這三個(gè)參數(shù)都可以解決并行復(fù)制中的一些指定的錯(cuò)誤，例如duplicate key 1062錯(cuò)誤等，今天我們簡(jiǎn)單試驗(yàn)一下，這三個(gè)參數(shù)的區(qū)別：
01 sql_slave_skip_counter參數(shù)
這個(gè)參數(shù)的設(shè)置主要是為了跳過(guò)某些錯(cuò)誤的"eve
master 10.30.124.68
slave 10.30.124.128
這倆實(shí)例互為主從。我們創(chuàng)建測(cè)試表test.yeyz，并插入一些數(shù)據(jù)，其中id為主鍵，具有唯一性，如下：
master上
mysql:(none)22:25:56>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| +----+------+ 4rowsinset(0.00sec)
slave上
mysql:(none)22:25:38>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| +----+------+ 5rowsinset(0.00sec)
我們可以發(fā)現(xiàn)，從節(jié)點(diǎn)的數(shù)據(jù)比主節(jié)點(diǎn)多一條，多了id=5的記錄，然后我們?cè)谥鞴?jié)點(diǎn)上插入數(shù)據(jù)：
mysql:(none)22:26:06>>insertintotest.yeyzvalues(5,5),(6,6); QueryOK,2rowsaffected(0.00sec) Records:2Duplicates:0Warnings:0
此時(shí)觀察從節(jié)點(diǎn)：
mysql:(none)22:26:34>>showslavestatus\G Master_Host:10.30.124.68 Master_User:dba_repl Master_Port:4306 Connect_Retry:60 Master_Log_File:mysqlbin.000002 Read_Master_Log_Pos:523 Relay_Log_File:slave-relay-bin.000002 Relay_Log_Pos:319 Relay_Master_Log_File:mysqlbin.000002 Slave_IO_Running:Yes Slave_SQL_Running:No Last_Errno:1062 Last_Error:Coordinatorstoppedbecausetherewereerror(s) intheworker(s).Themostrecentfailurebeing: Worker0failedexecutingtransaction'ANONYMOUS'at masterlogmysqlbin.000002,end_log_pos492. Seeerrorlogand/orperformance_schema.replication_applier_status_by_worker tableformoredetailsaboutthisfailureorothers,ifany. Skip_Counter:0
可以發(fā)現(xiàn)，從節(jié)點(diǎn)已經(jīng)SQL線程斷開(kāi)了， 這個(gè)時(shí)候，在主節(jié)點(diǎn)上查詢這個(gè)錯(cuò)誤position 492處的binlog，可以看到：
mysql:(none)22:30:28>>showbinlogeventsin'mysqlbin.000002'from194; +-----------------+-----+----------------+-----------+-------------+--------------------------------------------+ |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|#insertintotest.yeyzvalues(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:108flags:STMT_END_F| |mysqlbin.000002|492|Xid|192|523|COMMIT/*xid=38*/| +-----------------+-----+----------------+-----------+-------------+--------------------------------------------+ 6rowsinset(0.00sec)
從上面的binlog可以看出來(lái)，我們的一個(gè)insert操作實(shí)際上生成了5個(gè)enent，分別對(duì)應(yīng)的pos是從259~492，關(guān)于event，待會(huì)兒再說(shuō)。
因?yàn)橹鞴?jié)點(diǎn)上插入了id=5的記錄，跟從節(jié)點(diǎn)上的記錄沖突了，查看錯(cuò)誤日志，可以發(fā)現(xiàn)：
Duplicateentry'5'forkey'PRIMARY', Error_code:1062;handlererrorHA_ERR_FOUND_DUPP_KEY; theevent'smasterlogFIRST, end_log_pos492|2019-07-1622:26:25
我們通過(guò)sql_slave_skip_counter參數(shù)的設(shè)置來(lái)解決這個(gè)問(wèn)題，步驟如下：
mysql:(none)22:29:32>>stopslave; QueryOK,0rowsaffected,1warning(0.00sec) mysql:(none)22:32:45>>setglobalsql_slave_skip_counter=1; QueryOK,0rowsaffected(0.00sec) mysql:(none)22:33:06>>startslave;
在昨天的文章中我們說(shuō)過(guò)，sql_slave_skip_counter后面跟的值是event的個(gè)數(shù)，所以這里我們相當(dāng)于跳過(guò)了一個(gè)event，mysql中規(guī)定，如果跳過(guò)一個(gè)event之后，還在某一個(gè)事務(wù)里面，那么會(huì)繼續(xù)跳過(guò)這個(gè)事務(wù)。
使用這個(gè)參數(shù)跳過(guò)一個(gè)event之后，我們?cè)賮?lái)看從庫(kù)表中的數(shù)據(jù)和復(fù)制情況，可以看到：
slave表：
mysql:(none)22:33:10>>showslavestatus\G ***************************1.row*************************** Slave_IO_State:Waitingformastertosendevent Master_Host:10.30.124.68 Master_User:dba_repl Master_Port:4306 Connect_Retry:60 Master_Log_File:mysqlbin.000002 Read_Master_Log_Pos:523 Relay_Log_File:slave-relay-bin.000003 Relay_Log_Pos:319 Relay_Master_Log_File:mysqlbin.000002 Slave_IO_Running:Yes Slave_SQL_Running:Yes mysql:(none)22:33:16>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| +----+------+ 5rowsinset(0.00sec)
看看master表：
mysql:(none)22:33:36>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| |6|6| +----+------+ 6rowsinset(0.00sec)
可以發(fā)現(xiàn)，master中數(shù)據(jù)插入成功，而slave中數(shù)據(jù)插入失敗，也就是說(shuō)：
該參數(shù)跳過(guò)錯(cuò)誤的時(shí)候，會(huì)導(dǎo)致主從的數(shù)據(jù)不一致。
02 slave_skip_errors參數(shù)
這個(gè)參數(shù)是跳過(guò)制定的錯(cuò)誤，也就是說(shuō)，需要我們?cè)O(shè)置對(duì)應(yīng)的error_code，從下面的日志中的內(nèi)容可以看出，error_code的值為1062
Duplicateentry'5'forkey'PRIMARY', Error_code:1062;handlererrorHA_ERR_FOUND_DUPP_KEY; theevent'smasterlogFIRST, end_log_pos492|2019-07-1622:26:25
我們需要手動(dòng)將這個(gè)參數(shù)的值也該為1062，需要注意的是，這個(gè)參數(shù)的改動(dòng)需要重啟mysql服務(wù)，因?yàn)檫@個(gè)參數(shù)是一個(gè)只讀的參數(shù)。
修改后的情況如下：
mysql--dba_admin@127.0.0.1:(none)22:38:55>>showvariableslike'%errors%'; +--------------------+---------+ |Variable_name|Value| +--------------------+---------+ |max_connect_errors|1000000| |slave_skip_errors|1062| +--------------------+---------+ 2rowsinset(0.01sec)
此時(shí)我們更新master表和slave表的數(shù)據(jù)，更新后的情況如下：
master：
mysql:(none)22:39:15>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1||2|2| |3|3||4|4| |5|5||6|6| +----+------+ 6rowsinset(0.00sec)
slave上：
mysql:(none)22:40:15>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| |6|6| |7|7| +----+------+ 7rowsinset(0.00sec)
我們發(fā)現(xiàn)，slave表比master表多一條數(shù)據(jù)，也就是id=7的記錄，此時(shí)我們?cè)趍aster上執(zhí)行：
mysql:(none)22:34:15>>insertintotest.yeyzvalues(7,7),(8,8); QueryOK,2rowsaffected(0.00sec) Records:2Duplicates:0Warnings:0
查看slave上面的復(fù)制情況和數(shù)據(jù)情況，如下：
mysql:(none)22:39:05>>showslavestatus\G ***************************1.row*************************** Slave_IO_State:Waitingformastertosendevent Master_Host:10.30.124.68 Master_User:dba_repl Master_Port:4306 Connect_Retry:60 Master_Log_File:mysqlbin.000002 Read_Master_Log_Pos:852 Relay_Log_File:slave-relay-bin.000005 Relay_Log_Pos:648 Relay_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*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| |6|6| |7|7| +----+------+ 7rowsinset(0.00sec)
可以看到，復(fù)制沒(méi)有出現(xiàn)錯(cuò)誤，即使從庫(kù)上已經(jīng)有id=7的記錄。而且發(fā)現(xiàn)，從庫(kù)的數(shù)據(jù)跟之前保持一致，也就是說(shuō)，主庫(kù)插入的id=8的記錄沒(méi)有被同步過(guò)來(lái)。
總結(jié)一下：該參數(shù)在跳過(guò)復(fù)制錯(cuò)誤的時(shí)候，需要重啟mysql服務(wù)，然后可能導(dǎo)致主從數(shù)據(jù)不一致。
03 slave-skip-errors=N參數(shù)
再看最后一個(gè)參數(shù)，這個(gè)參數(shù)表示的是并行復(fù)制過(guò)程中的從庫(kù)復(fù)制模式，默認(rèn)值是strict嚴(yán)格模式，和上面一樣，我們先看主庫(kù)和從庫(kù)的數(shù)據(jù)情況：
master數(shù)據(jù)：
mysql:(none)22:39:20>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| |6|6| |7|7| |8|8| +----+------+ 8rowsinset(0.00sec)
slave數(shù)據(jù)：
mysql:(none)22:42:46>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| |6|6| |7|7| |8|8| |9|9| +----+------+ 9rowsinset(0.00sec)
此時(shí)我們?cè)趶膸?kù)上修改參數(shù)如下：
mysql:(none)22:42:59>>showvariableslike'%exec%'; +----------------------------------+--------+ |Variable_name|Value| +----------------------------------+--------+ |gtid_executed_compression_period|1000| |max_execution_time|0| |rbr_exec_mode|STRICT| |slave_exec_mode|STRICT| +----------------------------------+--------+ 4rowsinset(0.00sec) mysql:(none)22:44:05>>setglobalslave_exec_mode='IDEMPOTENT'; QueryOK,0rowsaffected(0.00sec) mysql:(none)22:44:10>>showvariableslike'%exec%'; +----------------------------------+------------+ |Variable_name|Value| +----------------------------------+------------+ |gtid_executed_compression_period|1000| |max_execution_time|0| |rbr_exec_mode|STRICT| |slave_exec_mode|IDEMPOTENT| +----------------------------------+------------+ 4rowsinset(0.00sec)
修改完參數(shù)，我們?cè)谥鲙?kù)上進(jìn)行insert操作：
insert into test.yeyz values (9,9),(10,10);
查看從庫(kù)的復(fù)制狀態(tài)和數(shù)據(jù)情況，如下：
mysql:(none)22:44:14>>showslavestatus\G ***************************1.row*************************** Slave_IO_State:Waitingformastertosendevent Master_Host:10.30.124.68 Master_User:dba_repl Master_Port:4306 Connect_Retry:60 Master_Log_File:mysqlbin.000002 Read_Master_Log_Pos:1183 Relay_Log_File:slave-relay-bin.000007 Relay_Log_Pos:650 Relay_Master_Log_File:mysqlbin.000002 Slave_IO_Running:Yes Slave_SQL_Running:Yes 1rowinset(0.00sec) mysql:(none)22:44:38>>select*fromtest.yeyz; +----+------+ |id|age| +----+------+ |1|1| |2|2| |3|3| |4|4| |5|5| |6|6| |7|7| |8|8| |9|9| |10|10| +----+------+ 10rowsinset(0.00sec)
可以發(fā)現(xiàn)，既沒(méi)有出現(xiàn)復(fù)制錯(cuò)誤，主庫(kù)上插入的數(shù)據(jù)也同步過(guò)來(lái)了。
總結(jié)一下：
- slave_exec_mode參數(shù)；
- sql_slave_skip_counter=N參數(shù);
- slave-skip-errors=N參數(shù)。
這三個(gè)參數(shù)都能解決復(fù)制過(guò)程中的不一致情況，區(qū)別如下：
slave_exec_mode參數(shù)可以保證主從數(shù)據(jù)一致，其他兩個(gè)不可以。
slave-skip-errors參數(shù)可以跳過(guò)制定的錯(cuò)誤，但是需要重啟實(shí)例，不能保證數(shù)據(jù)一致。
sql_slave_skip_counter參數(shù)需要在偏移量的復(fù)制模式下使用，不能保證數(shù)據(jù)一致。
以上就是MySQL復(fù)制問(wèn)題的三個(gè)參數(shù)分析的詳細(xì)內(nèi)容，更多關(guān)于MySQL復(fù)制問(wèn)題的資料請(qǐng)關(guān)注本站其它相關(guān)文章！
版權(quán)聲明：本站文章來(lái)源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有，歡迎引用、轉(zhuǎn)載，請(qǐng)保持原文完整并注明來(lái)源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站，禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像，否則將依法追究法律責(zé)任。本站部分內(nèi)容來(lái)源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來(lái)，僅供學(xué)習(xí)參考，不代表本站立場(chǎng)，如有內(nèi)容涉嫌侵權(quán)，請(qǐng)聯(lián)系alex-e#qq.com處理。
關(guān)注官方微信