MySQL 內建複寫功能測試實戰（三）：改進連線程序、容錯切換邏輯、負載均衡考量與生產建議

系列完結篇。前兩篇完成「主從互為主備」雙向複寫配置，本篇解決應用層如何**智能連線、容錯切換、負載分發**，並給出生產環境關鍵建議。

改進版資料庫連線函數：帶超時偵測的雙主容錯

原版 mysql_connect 無連線超時參數，整機掛掉時會無限阻塞。改用 fsockopen 先偵測 3306 端口可達性，再建立 MySQL 連線，實現**可控超時、快速失效轉移**。

關鍵優勢：
• 可調超時：避免整機掛掉導致 PHP-FPM 進程卡死。
• 端口先偵測：MySQL 進程掛掉但機器存活時，fsockopen 立即失敗（Connection refused），毫秒級切換。
• 應用層決策：不依賴中間件，邏輯透明可控。

結論與生產環境核心建議

1. 快照一致性是複寫生命線

• 建立快照時**必須先關閉二進制日誌**（或鎖表 FLUSH TABLES WITH READ LOCK），再複製資料檔，最後重新啟用 Binlog。
• 否則備庫啟動時重放 Binlog 會因主鍵衝突、重複鍵報錯導致 SQL 執行緒停止。

2. 雙主複寫 ≠ 寫入負載均衡

• 自增衝突：雙主同時寫入易產生相同 auto_increment 值，導致複寫中斷。
• 解決：auto_increment_increment=2 + auto_increment_offset=1/2 分配奇偶 ID，**但仍不解決業務邏輯衝突（同一行並發更新）**。
• **建議**：雙主僅做**高可用（單寫單備）**，寫入全部導向 Active Master，讀請求可分流到 Standby（需容忍秒級延遲）。

3. 監控複寫健康度（必做）

• SHOW SLAVE STATUS\G 關鍵指標：
  • Slave_IO_Running: Yes、Slave_SQL_Running: Yes
  • Seconds_Behind_Master: 0（或極小）
  • Last_IO_Error、Last_SQL_Error 為空
• 整合監控：Nagios/Zabbix/Prometheus + mysql_replication_* 指標，告警閾值：延遲 > 30s、SQL 執行緒停止、IO 執行緒斷開。

4. 故障切換自動化（MHA / Orchestrator / GTID + ProxySQL）

• 手工切換不可接受，生產必須部署**自動故障轉移工具**：
  • MHA (Master High Availability)：Perl 實現，支援 GTID、快速切換、備庫提升。
  • Orchestrator：Go 實現、Web UI、拓撲視覺化、支援 GTID、自動修復拓撲。
  • ProxySQL + GTID：中間件層路由、讀寫分離、故障自動切換、查詢重寫、熔斷限流。

5. 升級策略：利用複寫實現零停機升級

1. 備庫先升級至目標版本，驗證複寫正常。
2. 應用流量切換至備庫（升級後版本）。
3. 原主庫升級，驗證後切回或雙主共存。

系列總結

1. （一）單向主從配置：快照建立、Binlog 啟用、備庫掛載、CHANGE MASTER TO、驗證。
2. （二）雙主互備配置：雙向 CHANGE MASTER TO、GRANT FILE、相互複寫、應用連線邏輯初版。
3. （三）容錯連線函數、負載均衡誤區、生產建議（快照一致性、監控、自動切換、零停機升級） ← 當前篇

MySQL 複寫雖非分散式共識協議（如 Raft/Paxos），但配合 GTID、半同步、自動故障轉移工具，已能支撐高可用生產架構。核心在於：**嚴格快照一致性、持續監控、自動化切換、讀寫分離架構**。