故障機器修復重啟狂拉 Binlog 導致主庫網路擁塞：根因分析與預防機制

故障機器修復重啟狂拉 Binlog 導致主庫網路擁塞：根因分析與預防機制

事件回顧

一週前某 MySQL 伺服器硬體故障停機，今日修復開機後，上面 4 個 MySQL 實例自動啟動並瘋狂拉取主庫 Binlog。因停機時間長、日誌差異大（每實例日增 ~6GB，4 實例一週約 160GB+），導致主庫網路頻寬被佔滿，業務感知延遲明顯，持續 17 分鐘。

現象與排查

• 初期完全不知情，僅收到網路團隊回報「某 MySQL 機器流量異常大」
• SHOW PROCESSLIST、全量日誌、慢查詢日誌均無異常
• 監控顯示該時段讀 IO 驟升
• 歷史 PROCESSLIST 發現 replication user 狀態為 Waiting for net，IP 確認為週前故障的 Slave

根因結論

1. 故障機器修復開機時間不可控、無人知悉
2. 此類案例典型且可預期，但團隊缺乏預警意識與機制
3. 網路流量監控缺失，無法第一時間發現異常

解決與預防方案

1. 取消開機自啟 MySQL： 所有伺服器設定 chkconfig mysqld off 或 systemctl disable mysqld，開機後人工啟動並手動 STOP SLAVE，確認無誤後再 START SLAVE。
2. 建立故障機器追蹤機制： 硬體故障報修後，指定專人追蹤修復進度與開機時間，開機前協調 DBA 評估 Binlog 差異與網路影響。
3. 啟用流量監控告警： 部署網路流量監控（如 Zabbix、Prometheus + Node Exporter），設定閾值告警。
4. 納入操作手冊： 將「故障機器重啟 Binlog 洪峰」列入常見故障預防清單，新人培訓必講。

補充建議

若實例較多，人工啟動確實繁瑣，可開發自動化腳本：開機後檢測主從延遲、Binlog 差異大小，若超過閾值則延遲啟動或限速同步（slave_max_allowed_packet、網路限速 tc/qdisc），人工確認後再全速同步。