MySQL Bug 揭秘：server_id 未顯式設置時默認為 1 導致主從復制失效

故障現場

同事搭建主從復制，從庫報錯：

Got fatal error 1236 from master when reading data from binary log: 
'Misconfigured master - server id was not set'

現象分析

• 主庫 SHOW VARIABLES LIKE 'server_id'; 顯示 1 (配置文件未顯式設置)。
• 從庫 server_id = 2 (配置文件顯式設置)。
• 主庫版本較低，從庫版本較高，初步懷疑版本不兼容。

根因確認：MySQL 官方 Bug

查閱 MySQL Bug 列表發現：**若配置文件中未顯式設置 server-id，MySQL 會默認將其置為 1，但內部標記為「未設置」**，導致啟用 Binlog 時不寫入真實 Server ID 到事件中，從庫讀取到 Server ID = 0 拒絕復制。

關鍵點： SHOW VARIABLES 顯示 1 **≠** 實際已正確設置。必須在 my.cnf 中顯式寫入 server-id = 1 (或任意非 0 唯一值)。

驗證與修復

1. 主庫 my.cnf [mysqld] 區塊添加：server-id = 1 (或其他唯一正整數)。
2. 重啟主庫 MySQL 服務。
3. 從庫重新 CHANGE MASTER TO ...; START SLAVE;。
4. 檢查 SHOW SLAVE STATUS\G 確認 Slave_IO_Running: Yes, Slave_SQL_Running: Yes。

最佳實踐：server-id 分配規範

• 全局唯一：集群內所有節點 (主、從、備、延遲從) **絕對不能重複**。
• 有意義的編碼：建議 server-id = 機房ID * 1000 + 機架ID * 10 + 節點序號，如 1001, 1002, 2001。
• 避開 0 和 1：0 為非法值；1 為默認值，極易衝突。
• 配置管理納入版本控制**：my.cnf 必須由 Ansible/Puppet/Chef/SaltStack 下發，禁止手工修改。

教訓總結

1. 默認值 ≠ 正確配置：關鍵參數 (server-id, innodb_buffer_pool_size 等) **必須顯式寫入配置文件**，不能依賴默認值。
2. 版本差異是紅鯡魚**：故障初期易誤判為版本問題，實為配置缺失。
3. 變更前檢查清單：搭建復制前，雙方必須執行 SHOW VARIABLES LIKE 'server_id'; 並對照 my.cnf 確認顯式配置。