MySQL 複制兼容性矩陣：版本升級與主從匹配全指南

二進制日誌格式演進史

版本兼容性核心規則

1. 向後兼容：Slave 版本 ≥ Master 版本通常安全（新版本能解析舊格式）。
2. 向前不兼容：Master 版本 > Slave 版本可能導致 Slave 無法解析新事件。
3. 同主版本號：4.1.x 與 4.0.x Binlog 格式相同，互相兼容。
4. 例外：4.0.0-4.0.2 (Alpha) 格式特殊，不可與後續版本混用。

主從版本匹配建議矩陣

升級複制拓撲的標準流程

1. 升級 Slave 先行：按從庫→主庫順序升級，確保 Slave 能解析 Master 現有 Binlog。
2. 驗證複制延遲：升級後觀察 Seconds_Behind_Master 歸零。
3. 切換主庫：若需升級 Master，先提升一 Slave 為新 Master，再升級舊 Master 作為 Slave 加入。
4. 統一 binlog_format：建議全鏈路設為 ROW 或 MIXED，減少非確定性函數導致的不一致。

常見坑點與規避

• GTID 模式：5.6+ 引入 GTID，舊版本無法理解，升級時需關閉 GTID 或全鏈路同步開啟。
• 字符集變更：升級伴隨 utf8mb4 遷移時，確保連接層 SET NAMES 一致。
• 系統表結構變化：mysql.user 等系統表結構變更，升級後必須執行 mysql_upgrade。

官方資源

最新兼容性文檔請參考：MySQL Replication Compatibility Between Versions

總結

MySQL 複制兼容性遵循「Slave 版本不低於 Master」原則。生產環境升級必須制定詳細回滾預案，優先在測試環境驗證完整鏈路，避免數據不一致或複制中斷。