故障現象

配置 MySQL Replication 時，分兩步執行 CHANGE MASTER TO 後啟動 Slave，報錯：

ERROR: Could not initialize master info structure,
more error messages can be found in the MySQL error log

錯誤日誌中無明顯異常，SHOW SLAVE STATUS\G 顯示 Slave_IO_Running: No。

根因分析

MySQL 內部維護 master.info（舊版）或 slave_master_info 表（5.6+）記錄主庫坐標。若先後分開執行兩條 CHANGE MASTER TO，中間未 START SLAVE，會導致元數據不一致，內部結構初始化失敗。常見於手動分步配置或腳本中斷的場景。

標準修復步驟

1. 重置 Slave 元數據（核心步驟）：

   STOP SLAVE;
   RESET SLAVE ALL;  -- 5.5+ 使用 RESET SLAVE ALL 清除所有同步元數據
   

2. 重新配置主庫坐標（根據實際主庫 Binlog 位置）：

   CHANGE MASTER TO
     MASTER_HOST='master_host',
     MASTER_USER='repl_user',
     MASTER_PASSWORD='repl_pass',
     MASTER_LOG_FILE='mysql-bin.000001',
     MASTER_LOG_POS=107;
   

3. 啟動同步並驗證：

   START SLAVE;
   SHOW SLAVE STATUS\G
   -- 確認 Slave_IO_Running: Yes, Slave_SQL_Running: Yes
   

為什麼要 RESET SLAVE？

• 清除損壞的 master.info / relay-log.info 及內存中殘留的同步坐標。
• 將 MASTER_LOG_FILE、MASTER_LOG_POS 重置為空，避免「impossible position」錯誤。
• RESET SLAVE ALL 還會清除 CHANGE MASTER TO 設定的連接參數，需重新指定。

進階排查：若重置後仍失敗

1. 檢查主庫 Binlog 是否存在：SHOW BINARY LOGS; 確認 MASTER_LOG_FILE 在列表中。
2. 主庫 max_binlog_size、expire_logs_days 導致舊 Binlog 已過期清理，需重新搭建 Slave（全量備份 + 當前 Binlog 位置）。
3. 網路不通：telnet master_host 3306、防火牆、安全組、bind-address 配置。
4. 權限不足：主庫授權 GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip' IDENTIFIED BY 'pass';。
5. 版本不兼容：主庫版本高於從庫可能導致事件格式無法解析，建議主從版本一致或主庫版本 ≤ 從庫版本。

預防最佳實踐

• 使用單條 CHANGE MASTER TO 包含所有參數，避免分步執行。
• 自動化部署工具（Ansible、Terraform）管理 Replication 配置，確保冪等性。
• 監控 Seconds_Behind_Master、Slave_IO_Running、Slave_SQL_Running 關鍵指標，設置告警。
• 定期演練主從切換與重建流程。

總結

Could not initialize master info structure 本質是 Slave 端同步元數據不一致導致的初始化失敗。通過 RESET SLAVE ALL 徹底清理舊元數據，再重新指定主庫坐標啟動，即可快速恢復同步。規範化配置流程與監控體系是避免此類問題復發的關鍵。