展開閱讀全文

今天碰到一個有些奇怪的問題，有一套環(huán)境，在主從復制的時候有一些問題。

大體的流程設計如下：

三個節(jié)點位于三個不同的區(qū)域，因為節(jié)點1和節(jié)點3之間的網絡存在問題，所以走了節(jié)點2來中轉，由此可見延遲是難免的，但是延遲不能太大。最終的數(shù)據(jù)還是要通過節(jié)點3來做統(tǒng)計分析查詢。這套環(huán)境的數(shù)據(jù)量不大，但是數(shù)據(jù)變更貌似是比較頻繁。早上開發(fā)的同事反饋，節(jié)點同步感覺延遲很大，想讓我?guī)兔纯吹降资悄睦锍隽藛栴}。

查看節(jié)點1，節(jié)點2沒有延遲，問題就出在節(jié)點2到節(jié)點3的延遲。

在節(jié)點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)在日志應用中出現(xiàn)了1032的錯誤，即刪除的數(shù)據(jù)在從庫中找不到。一般來看這類問題，感覺好像說小也小，那skip一下吧，發(fā)現(xiàn)這個不是權宜之計，因為skip了這個問題之后接著又碰到了同樣的問題，所以反反復復修改skip本身就是一件隔靴撓癢的事情，而且實際上數(shù)據(jù)已經不一致了。

因為需求緊迫，時間又比較緊張，數(shù)據(jù)的延遲較大，所以簡單評估之后發(fā)現(xiàn)還是重建從庫。

當然這個步驟就很常規(guī)了。我也簡單列舉一下：

因為是多實例的場景，所以使用了如下的命令來導出：

/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

然后在各種網絡層面周旋，總算是把這個dump從節(jié)點2拷貝到了從庫環(huán)境節(jié)點3

然后在節(jié)點3停止slave,開始導入數(shù)據(jù)：

gunzip < test.sql.gz | /opt/mysql/bin/mysql? --socket=/home/bmbidb/mysql.sock --port=3307

start slave

接著開始change master,當然這個時候對于MASTER_LOG_FILE，MASTER_LOG_POS可以通過dump來得到這些信息

gunzip < tes.sql.gz | head -50

會發(fā)現(xiàn)下面這么一段內容：

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000008', MASTER_LOG_POS=241903809;

這就是需要我們關注的地方，然后直接使用即可。

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;

這樣從庫的設置就完成了。

然后在下午的晚些時間又碰到了類似的問題，這可讓我很糾結了，不可能一出現(xiàn)這種情況我就重建從庫吧。

排除了很多潛在的原因，包括sync_binlog,表結構差異，節(jié)點中的數(shù)據(jù)庫權限，表的存儲引擎等。貌似還是沒有找到要領。

通過mysqlbinlog去解析relay日志，依舊是無功而返。

/opt/mysql/bin/mysqlbinlog? -vv relaylog.05???? --base64-output decode-rows > relay05.tmp

所以這個問題還是很讓人糾結的。

在同事的協(xié)助下，暫時使用了一個臨時方案先來過渡。對于這類的DML操作如果數(shù)據(jù)不存在，可以選擇忽略，即設置slave_exec_mode為IDEMPOTENT，而默認職位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)

修改完成后，這類問題暫時告一段落，還需要找到根本的原因。這種情況下比對了部分的數(shù)據(jù)，沒有發(fā)現(xiàn)其他的數(shù)據(jù)沖突，但是解決方案也需要一個合理的解釋。我們下一篇來繼續(xù)聊聊這個，應該會有一個答復。

本文首發(fā)在云棲社區(qū)，遵循云棲社區(qū)版權聲明：本文內容由互聯(lián)網用戶自發(fā)貢獻，版權歸用戶作者所有，云棲社區(qū)不為本文內容承擔相關法律責任。云棲社區(qū)已在2020年6月升級到阿里云開發(fā)者社區(qū)。如果您發(fā)現(xiàn)有涉嫌抄襲的內容，請?zhí)顚懬謾嗤对V表單進行舉報，一經查實，阿里云開發(fā)者社區(qū)將協(xié)助刪除涉嫌侵權內容。

網友評論

登錄后評論

0/500

評論

總結

以上是生活随笔為你收集整理的mysql 级联同步不成功_MySQL级联复制的同步问题（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。