原創作者：愛可生開源社區

本文我們來看一個場景，兩臺MySQL實例使用主從復制，當master故障，觸發高可用切換，新master上線后，通過備份重建舊master并建立復制后，數據發生丟失。

以下我們通過圖解還原一遍當時的場景：

注：圖中標注的id指的是MySQL的server_id

server_id配置：

默認值1或0

需要配置時通過參數server-id指定

背景：

• 當配置MySQL復制時，server_id是必填項，用來區分復制拓撲中的各個實例，例如在循環的級聯復制中(A=>B=>C=>A)，避免重復數據不必要的復制(C=>A數據重復，不必要)
• 當slave的io線程發現binlog中的server_id與自身一樣時，默認不會將該binlog寫入自身的relay log中，即跳過了該數據的復制，同時也能減少寫relay log對磁盤的壓力
• 然而這種機制在高可用切換場景下會引入潛在的隱患：
• 隱患一：
• 如上圖所示，從備份恢復的舊master仍沿用了原來的server_id A，導致io線程跳過了A:2事務，最終丟失了A:2的數據
• 隱患二：
• 級聯復制中，當不相鄰實例的server_id相同時，也會出現復制數據丟失
• 上述兩種隱患的存在都是因為在復制拓撲中非直接相連的MySQL server_id重復。在普通的一對主從復制中，slave的io線程會檢查與自己相連的master的server_id是否與自身重復，若發現重復會停止復制拋出錯誤
• 注：可通過配置--replicate-same-server-id改變以上默認行為

使用建議：

• 配置MySQL復制時，為每個實例配置不同的server_id
• 通過備份工具還原實例后，為實例配置一個新的server_id

附加題：

除了server_id，MySQL5.6起引入了server_uuid

server_uuid配置：

當MySQL啟動時

嘗試從 data_dir/auto.cnf中讀取 uuid

如果1嘗試失敗，則生成一個新的uuid并寫入data_dir/auto.cnf

背景：

• 主從復制中，要求master和slave的server_uuid不同，否則在復制初始化時會出現報錯
• GTID就是使用了server_uuid做為全局唯一的標識

使用建議：

• 如果直接拷貝master的數據文件來建立slave，注意要刪除auto.cnf，重啟使MySQL重新生成一個新的server_uuid，否則復制將會異常

本文參考：

https://dev.mysql.com/doc/refman/8.0/en/replication-options-slave.html

總結

以上是生活随笔為你收集整理的mysql数据丢失_图解MySQL | 「原理解析」 MySQL使用固定的server_id导致数据丢失的全部內容，希望文章能夠幫你解決所遇到的問題。

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