MySQL級聯複製的同步問題(一)
今天碰到一個有些奇怪的問題,有一套環境,在主從複製的時候有一些問題。
大體的流程設計如下:
三個節點位於三個不同的區域,因為節點1和節點3之間的網路存在問題,所以走了節點2來中轉,由此可見延遲是難免的,但是延遲不能太大。最終的資料還是要透過節點3來做統計分析查詢。這套環境的資料量不大,但是資料變更貌似是比較頻繁。早上開發的同事反饋,節點同步感覺延遲很大,想讓我幫忙看看到底是哪裡出了問題。
檢視節點1,節點2沒有延遲,問題就出在節點2到節點3的延遲。
在節點3中檢視slave狀態:
> 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)
發現在日誌應用中出現了1032的錯誤,即刪除的資料在從庫中找不到。一般來看這類問題,感覺好像說小也小,那skip一下吧,發現這個不是權宜之計,因為skip了這個問題之後接著又碰到了同樣的問題,所以反反覆覆修改skip本身就是一件隔靴撓癢的事情,而且實際上資料已經不一致了。
因為需求緊迫,時間又比較緊張,資料的延遲較大,所以簡單評估之後發現還是重建從庫。
當然這個步驟就很常規了。我也簡單列舉一下:
因為是多例項的場景,所以使用瞭如下的命令來匯出:
/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從節點2複製到了從庫環境節點3
然後在節點3停止slave,開始匯入資料:
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
會發現下面這麼一段內容:
-- 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;
這樣從庫的設定就完成了。
然後在下午的晚些時間又碰到了類似的問題,這可讓我很糾結了,不可能一出現這種情況我就重建從庫吧。
排除了很多潛在的原因,包括sync_binlog,表結構差異,節點中的資料庫許可權,表的儲存引擎等。貌似還是沒有找到要領。
透過mysqlbinlog去解析relay日誌,依舊是無功而返。
/opt/mysql/bin/mysqlbinlog -vv relaylog.05 --base64-output decode-rows > relay05.tmp
所以這個問題還是很讓人糾結的。
在同事的協助下,暫時使用了一個臨時方案先來過渡。對於這類的DML操作如果資料不存在,可以選擇忽略,即設定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)
修改完成後,這類問題暫時告一段落,還需要找到根本的原因。這種情況下比對了部分的資料,沒有發現其他的資料衝突,但是解決方案也需要一個合理的解釋。我們下一篇來繼續聊聊這個,應該會有一個答覆。
大體的流程設計如下:
三個節點位於三個不同的區域,因為節點1和節點3之間的網路存在問題,所以走了節點2來中轉,由此可見延遲是難免的,但是延遲不能太大。最終的資料還是要透過節點3來做統計分析查詢。這套環境的資料量不大,但是資料變更貌似是比較頻繁。早上開發的同事反饋,節點同步感覺延遲很大,想讓我幫忙看看到底是哪裡出了問題。
檢視節點1,節點2沒有延遲,問題就出在節點2到節點3的延遲。
在節點3中檢視slave狀態:
> 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)
發現在日誌應用中出現了1032的錯誤,即刪除的資料在從庫中找不到。一般來看這類問題,感覺好像說小也小,那skip一下吧,發現這個不是權宜之計,因為skip了這個問題之後接著又碰到了同樣的問題,所以反反覆覆修改skip本身就是一件隔靴撓癢的事情,而且實際上資料已經不一致了。
因為需求緊迫,時間又比較緊張,資料的延遲較大,所以簡單評估之後發現還是重建從庫。
當然這個步驟就很常規了。我也簡單列舉一下:
因為是多例項的場景,所以使用瞭如下的命令來匯出:
/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從節點2複製到了從庫環境節點3
然後在節點3停止slave,開始匯入資料:
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
會發現下面這麼一段內容:
-- 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;
這樣從庫的設定就完成了。
然後在下午的晚些時間又碰到了類似的問題,這可讓我很糾結了,不可能一出現這種情況我就重建從庫吧。
排除了很多潛在的原因,包括sync_binlog,表結構差異,節點中的資料庫許可權,表的儲存引擎等。貌似還是沒有找到要領。
透過mysqlbinlog去解析relay日誌,依舊是無功而返。
/opt/mysql/bin/mysqlbinlog -vv relaylog.05 --base64-output decode-rows > relay05.tmp
所以這個問題還是很讓人糾結的。
在同事的協助下,暫時使用了一個臨時方案先來過渡。對於這類的DML操作如果資料不存在,可以選擇忽略,即設定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)
修改完成後,這類問題暫時告一段落,還需要找到根本的原因。這種情況下比對了部分的資料,沒有發現其他的資料衝突,但是解決方案也需要一個合理的解釋。我們下一篇來繼續聊聊這個,應該會有一個答覆。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2122535/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL級聯複製中資料同步MySql
- MySQL級聯複製中的資料同步(第二篇)MySql
- 多級複製的資料不同步問題
- MySQL 8 複製(一)——非同步複製MySql非同步
- MySQL的非同步複製和半同步複製MySql非同步
- MySQL 5.5級聯複製配置流程MySql
- MySQL複製的奇怪問題MySql
- MySQL入門--MySQL複製技術之主從從級聯複製MySql
- MySQL的半同步複製MySql
- MySQL 半同步複製MySql
- MySQL半同步複製MySql
- MySQL 8 複製(二)——半同步複製MySql
- MySQL主從複製之半同步複製MySql
- MySQL主從複製之非同步複製MySql非同步
- mysql 5.7半同步複製MySql
- MySQL的主從複製、半同步複製、主主複製詳解MySql
- mysql半同步複製的設定MySql
- MySQL主從複製、半同步複製和主主複製MySql
- MySQL主從複製問題解決一例MySql
- MySQL主從複製、半同步複製和主主複製概述MySql
- Mysql5.7半同步複製MySql
- MySQL 8 複製(九)——組複製聯機配置MySql
- MySQL5.7主從複製-半同步複製搭建MySql
- mysql5.5中的半同步複製MySql
- 配置mysql5.5主從複製、半同步複製、主主複製MySql
- 【MySQL】半同步與增強半同步複製MySql
- Mysql 5.6庫級表級複製的搭建MySql
- MySQL 半同步複製+MMM架構MySql架構
- MySQL主從雙向同步複製MySql
- MySQL半同步複製--after_rollbackMySql
- mysql5.5半同步複製探究MySql
- MySQL之 從複製延遲問題排查MySql
- mysql線上建立半同步複製的從庫MySql
- 如何解決MySQL主從複製太慢的問題MySql
- mysql的主從複製資料延遲問題MySql
- MySQL 5.7 多主一從(多源複製)同步配置MySql
- MySQL(二):主從複製結構、半同步複製、雙主複製結構、利用SSL實現安全的MySQL主從複製MySql
- MySQL入門--MySQL複製技術之部署中遇到的問題MySql