MySQL 級聯複製的坑，我幫你們踩了。
作者：蔣士峯，愛可生 DBA 團隊成員，熟悉 MySQL，Oracle 等數據庫。每天的積累，時間久了，會帶來不一樣的收貨。
愛可生開源社區出品，原創內容未經授權不得隨意使用，轉載請聯繫小編並註明來源。
本文約 1200 字，預計閱讀需要 3 分鐘。
業務場景
在日常運維的某個系統下，由於之前數據庫主機所用硬盤是傳統機械硬盤，容量小，傳輸速度低，並且數據庫服務器整體性能不高。隨着業務訪問量的增加，現有數據庫服務器無法滿足需求，所以需要搭建一套高性能的數據庫服務器，並且所用硬盤是 SSD。
由於原先數據庫採用的是主從複製架構，所以新搭建的數據庫也要採用主從架構。跟舊數據庫集羣組成一套級聯複製的 MySQL 數據庫集羣（舊集羣的主庫作爲主，新集羣的主庫爲舊集羣主庫的從，新集羣從庫還繼續爲新集羣主庫的從），先進行數據同步一段時間，再找時間點進行業務割接。
由此從 舊集羣主庫--->新集羣主庫--->新集羣從庫 之前形成了一條類似於鏈條式的同步關係，具體關係圖如下：
問題的發現
搭建完成新集羣，做級聯複製的時候，沒有發現任何錯誤，數據同步也是正常的。大概過了 15 天進行數據比對的時候，發現了一個重要問題：新集羣的主庫可以正常同步舊集羣主庫的新增數據，但是新集羣的從庫無法同步新集羣主庫的新增數據。
如圖所示：
問題分析
-
由於從新集羣的主庫到新集羣從庫無法正常同步，所以我們先分析了新集羣主庫的 binlog 日誌是否開啓，還有
log_slave_update是否也開啓了，只有開啓了，才能產生 binlog 做主從同步。發現都是開啓的，所以只能從其他方面去看。 -
除此之外，我們還專門在舊集羣主庫上進行了創建庫，插入數據操作，觀察 positon 位置點的變化信息。
創建庫，插入數據之前：
創建庫，插入數據之後：
重要問題：發現插入數據的時候，舊集羣主庫和新集羣主庫的 binlog 位置點都發生了變化，只有新集羣的從庫的 binlog 位置點一直沒變，這明顯是不正常的。
-
前面也確認了 binlog 相關參數都是開啓的。所以此時，我們只有把三臺數據庫的配置文件
my.cnf拿出來對比一下了，檢查一下是不是配置文件的相關參數出了問題。經過對比確認參數，發現了一個主要的問題：舊集羣的主庫的
server_id爲 1，新集羣的主庫的server_id爲 2，新集羣的從庫的server_id爲 1。這意味着什麼？舊集羣主庫的
server_id與新集羣從庫的server_id重複了。但是問題又來了，當時做主從的時候完全沒有報錯啊。那麼，級聯複製中，是不是也要保證所有的server_id不同呢？
- 帶着這個疑問，我們專門在本地環境搭建了一套類似於生產環境的級聯複製，並且隨意改動
server_id，然後插入數據，觀察一下數據同步情況。驗證了一條重要信息：級聯複製中，所有參與構建集羣的 MySQL 數據庫server_id不能相同，一旦相同，數據同步就會出現故障。
產生這一問題的根源
在項目中，數據集羣衆多，手動安裝工作量較大，所以本次安裝數據庫也是採用自動化安裝的，分配 server_id 的時候，也是 1 或者 2 隨機分配。所以才導致了本次新集羣從庫 server_id 跟舊集羣衝突了。
整改步驟
數據已經同步了 15 天了，但是我們的 binlog 只保存了 14 天，所以現在只有先修改一下 server_id，保證該級聯複製中所有數據庫的 server_id 都是不同的；然後再備份一下舊集羣主庫，恢復到新集羣，重做級聯複製。
帶來的啓示
- 使用級聯複製，一定要保證所有參與數據庫的
server_id不同。 - 要確 binlog 日誌以及相關參數是開啓的。
- 由於級聯複製存在各種小問題，所以日常生產中儘量少用級聯複製。
更多技術文章，請訪問：https://opensource.actionsky.com/
關於 SQLE
SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫，爲開發和運維提供流程自動化能力，提升上線效率，提高數據質量。