MySQL級聯復制的同步難題

2024-07-24 12:31:58

字體：大中小

來源：轉載

供稿：網友

今天碰到一個有些奇怪的問題，有一套環境，在主從復制的時候有一些問題。
大體的流程設計如下：

三個節點位于三個不同的區域，因為節點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本身就是一件隔靴撓癢的事情，而且實際上數據已經不一致了。
因為需求緊迫，時間又比較緊張，數據的延遲較大，所以簡單評估之后發現還是重建從庫。

在同事的協助下，暫時使用了一個臨時方案先來過渡。對于這類的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)
修改完成后，這類問題暫時告一段落，還需要找到根本的原因。這種情況下比對了部分的數據，沒有發現其他的數據沖突，但是解決方案也需要一個合理的解釋。我們下一篇來繼續聊聊這個，應該會有一個答復。

（編輯：武林網）

上一篇：相關MYSQL中FLOAT和DOUBLE類型的存儲

下一篇：mysql innodb cluster 創建