今天碰到一個(gè)有些奇怪的問(wèn)題，有一套環(huán)境，在主從復(fù)制的時(shí)候有一些問(wèn)題。
大體的流程設(shè)計(jì)如下：

三個(gè)節(jié)點(diǎn)位于三個(gè)不同的區(qū)域，因?yàn)楣?jié)點(diǎn)1和節(jié)點(diǎn)3之間的網(wǎng)絡(luò)存在問(wèn)題，所以走了節(jié)點(diǎn)2來(lái)中轉(zhuǎn)，由此可見(jiàn)延遲是難免的，但是延遲不能太大。最終的數(shù)據(jù)還是要通過(guò)節(jié)點(diǎn)3來(lái)做統(tǒng)計(jì)分析查詢。這套環(huán)境的數(shù)據(jù)量不大，但是數(shù)據(jù)變更貌似是比較頻繁。早上開(kāi)發(fā)的同事反饋，節(jié)點(diǎn)同步感覺(jué)延遲很大，想讓我?guī)兔纯吹降资悄睦锍隽藛?wèn)題。
查看節(jié)點(diǎn)1，節(jié)點(diǎn)2沒(méi)有延遲，問(wèn)題就出在節(jié)點(diǎn)2到節(jié)點(diǎn)3的延遲。
在節(jié)點(diǎn)3中查看slave狀態(tài)：
> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host:xxxx
                  Master_User: repl
                  Master_Port: 3307
                Connect_Retry: 10
              Master_Log_File: MySQL-bin.000009
          Read_Master_Log_Pos: 16186388
               Relay_Log_File: relay-bin.000004
                Relay_Log_Pos: 13599457
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB:
          Replicate_Ignore_DB:
...
                   Last_Errno: 1032
                   Last_Error: Could not execute Delete_rows event on table test_mbi.test_dist_online; Can't find record in 'test_dist_o
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 13599294
              Relay_Log_Space: 16304336
              Until_Condition: None
...
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
               Last_SQL_Errno: 1032
               Last_SQL_Error: Could not execute Delete_rows event on table test_mbi.test_dist_online; Can't find record in 'test_dist_o
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 23307
                  Master_UUID: 189a00c4-16a3-11e6-a678-06c76b65c01e
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State:
           Master_Retry_Count: 86400
1 row in set (0.00 sec)
發(fā)現(xiàn)在日志應(yīng)用中出現(xiàn)了1032的錯(cuò)誤，即刪除的數(shù)據(jù)在從庫(kù)中找不到。一般來(lái)看這類問(wèn)題，感覺(jué)好像說(shuō)小也小，那skip一下吧，發(fā)現(xiàn)這個(gè)不是權(quán)宜之計(jì)，因?yàn)閟kip了這個(gè)問(wèn)題之后接著又碰到了同樣的問(wèn)題，所以反反復(fù)復(fù)修改skip本身就是一件隔靴撓癢的事情，而且實(shí)際上數(shù)據(jù)已經(jīng)不一致了。
因?yàn)樾枨缶o迫，時(shí)間又比較緊張，數(shù)據(jù)的延遲較大，所以簡(jiǎn)單評(píng)估之后發(fā)現(xiàn)還是重建從庫(kù)。
當(dāng)然這個(gè)步驟就很常規(guī)了。我也簡(jiǎn)單列舉一下：
因?yàn)槭嵌鄬?shí)例的場(chǎng)景，所以使用了如下的命令來(lái)導(dǎo)出：
 /opt/mysql/bin/mysqldump -S /data2/bmbidb/mysql.sock --single-transaction --master-data=2  -B  test_ad test_mbi test_sys_mgr  |gzip > test.sql.gz
然后在各種網(wǎng)絡(luò)層面周旋，總算是把這個(gè)dump從節(jié)點(diǎn)2拷貝到了從庫(kù)環(huán)境節(jié)點(diǎn)3
然后在節(jié)點(diǎn)3停止slave,開(kāi)始導(dǎo)入數(shù)據(jù)：
gunzip < test.sql.gz | /opt/mysql/bin/mysql  --socket=/home/bmbidb/mysql.sock --port=3307
start slave
接著開(kāi)始change master,當(dāng)然這個(gè)時(shí)候?qū)τ贛ASTER_LOG_FILE，MASTER_LOG_POS可以通過(guò)dump來(lái)得到這些信息
 gunzip < tes.sql.gz | head -50
會(huì)發(fā)現(xiàn)下面這么一段內(nèi)容：
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000008', MASTER_LOG_POS=241903809;
這就是需要我們關(guān)注的地方，然后直接使用即可。
 CHANGE MASTER TO MASTER_HOST='xxxx',MASTER_USER='repl',MASTER_PASSWORD='xxxx',MASTER_PORT=3307,MASTER_LOG_FILE='mysql-bin.000008', MASTER_LOG_POS=241903809,MASTER_CONNECT_RETRY=10;
這樣從庫(kù)的設(shè)置就完成了。    
然后在下午的晚些時(shí)間又碰到了類似的問(wèn)題，這可讓我很糾結(jié)了，不可能一出現(xiàn)這種情況我就重建從庫(kù)吧。
排除了很多潛在的原因，包括sync_binlog,表結(jié)構(gòu)差異，節(jié)點(diǎn)中的數(shù)據(jù)庫(kù)權(quán)限，表的存儲(chǔ)引擎等。貌似還是沒(méi)有找到要領(lǐng)。
通過(guò)mysqlbinlog去解析relay日志，依舊是無(wú)功而返。
/opt/mysql/bin/mysqlbinlog  -vv relaylog.05     --base64-output decode-rows > relay05.tmp
所以這個(gè)問(wèn)題還是很讓人糾結(jié)的。
在同事的協(xié)助下，暫時(shí)使用了一個(gè)臨時(shí)方案先來(lái)過(guò)渡。對(duì)于這類的DML操作如果數(shù)據(jù)不存在，可以選擇忽略，即設(shè)置slave_exec_mode為IDEMPOTENT，而默認(rèn)職位STRICT
> set global slave_exec_mode='IDEMPOTENT';
Query OK, 0 rows affected (0.00 sec)
> stop slave;set global sql_slave_skip_counter=1;start slave;
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
Query OK, 0 rows affected (0.00 sec)
修改完成后，這類問(wèn)題暫時(shí)告一段落，還需要找到根本的原因。這種情況下比對(duì)了部分的數(shù)據(jù)，沒(méi)有發(fā)現(xiàn)其他的數(shù)據(jù)沖突，但是解決方案也需要一個(gè)合理的解釋。我們下一篇來(lái)繼續(xù)聊聊這個(gè)，應(yīng)該會(huì)有一個(gè)答復(fù)。




本文標(biāo)題：MySQL級(jí)聯(lián)復(fù)制的同步問(wèn)題（一）
URL網(wǎng)址：http://weahome.cn/article/pgoioj.html