MySQL 主從同步報錯「server ids equal」排查：隱藏 my.cnf 導致 server_id 未生效

故障現象

搭建一主三從後，所有 Slave 報錯：

Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server ids; these ids must be different for replication to work

排查過程

1. 檢查配置文件：/etc/my.cnf 中已設置 server_id=2（主庫為 1），並註釋掉默認 server_id=1
2. 查看運行時值：SHOW VARIABLES LIKE 'server_id'; → 返回 1 ❌
3. 嘗試動態修改：SET GLOBAL server_id=2; + START SLAVE; → 臨時恢復
4. 重啟驗證：systemctl restart mysqld → 再次查看變回 1 ❌

根因定位：多份 my.cnf 干擾

MySQL 啟動時按優先級讀取多個配置文件，後讀取者覆蓋先讀取者：

1. /etc/my.cnf
2. /etc/mysql/my.cnf
3. DATADIR/my.cnf  (如 /usr/local/mysql/data/my.cnf)
4. ~/.my.cnf

定位命令

find / -name "my.cnf" 2>/dev/null
# 發現 /usr/local/mysql/my.cnf 含有 server_id=1

解決

rm /usr/local/mysql/my.cnf  # 刪除干擾文件
systemctl restart mysqld
SHOW VARIABLES LIKE 'server_id';  # 返回 2 ✅

知識擴展：server_id 的關鍵作用

• 主從唯一標識：主庫、每個從庫的 server_id 必須全局唯一（正整數 1~2³²-1）
• Binlog 事件標記：每個 Binlog 事件攜帶產生者的 server_id
• 防環路檢測：Slave 讀取 Binlog 時，若遇到自身 server_id 產生的事件，則跳過（防止循環復制）
• GTID 組成：GTID = source_id:transaction_id，source_id 即 server_id（或自定義 UUID）

最佳實踐：避免配置文件衝突

相關參數：replicate-same-server-id

• 默認 0：Slave 跳過自身 server_id 的事件
• 設置 1：允許處理自身 server_id 事件（極少用，如特殊環形拓撲）
• 警告：開啟後極易導致循環復制，除非極度理解拓撲邏輯，否則保持默認 0

總結

「配置文件寫了不等於生效」。MySQL 多層級配置加載機制是運維隱形坑。
鐵律：find 定位所有 my.cnf → 只保留標準路徑 → 重啟驗證運行時值。
將此納入 MySQL 部署 SOP，杜絕「明明配了為什麼不生效」的靈異事件。