故障機修復重啟狂拉 Binlog 導致主庫網絡擁塞：根因復盤與防範機制

事件回顧

一台 MySQL 從庫因硬件故障停機一周。運維修復上架並**開機自啟 MySQL 實例**（4 個實例）。實例啟動後自動連接主庫拉取 Binlog，累積一周約 160GB+ 日志，瞬間佔滿主庫網卡帶寬，導致主庫業務感知延遲 17 分鐘。

現象與排查

• 監控發現主庫讀 IO 飆升、網卡流量異常
• SHOW PROCESSLIST 歷史記錄顯示復制用戶狀態 Waiting for net
• IP 定位為一周前故障的從庫

根因分析

解決方案與防範機制

1. 徹底禁用開機自啟，改為人工受控啟動

# 禁用開機自啟
systemctl disable mysqld@3306
systemctl disable mysqld@3307
# ... 所有實例

# 啟動腳本加入安全檢查
#!/bin/bash
# safe_start_mysql.sh
read -p "確認主庫網絡正常、無大促大促活動？(y/n) " confirm
[[ $confirm != "y" ]] && exit 1
systemctl start mysqld@3306
sleep 5
mysql -S /tmp/mysql3306.sock -e "STOP SLAVE;"
echo "實例 3306 已啟動並暫停復制，請人工確認後執行 START SLAVE"

2. 納入運維手冊與變更流程

• **故障機上架清單**：確認修復完成 → 通知 DBA → DBA 窗口期人工啟動 → STOP SLAVE → 確認主庫負載 → START SLAVE
• **變更單模板** 必填：預計拉取 Binlog 量、預估耗時、限速策略、回滾預案

3. 技術層面限速與緩衝（MySQL 8.0+ / 5.7 部分版本）

-- 從庫配置：限制復制 SQL 線程吞吐
SET GLOBAL slave_parallel_workers=4;  -- 並行復制
SET GLOBAL slave_pending_jobs_size_max=128M;  -- 佇列上限

-- 主庫配置：限制 Binlog 發送速率（需 patch 或 Proxy 層面限流）
-- 可考慮使用 MySQL Router / ProxySQL 做流量整形

4. 監控補齊

• 主庫網卡流量告警（閾值 70% 帶寬）
• 從庫 Seconds_Behind_Master 告警
• 從庫實例上線/下線狀態變更告警（心跳檢測）
• Binlog 積壓量監控（主庫 SHOW BINARY LOGS 統計）

總結

這是一個**典型的「已知風險、缺乏流程、監控缺位」導致的生產事故**。核心教訓：

1. 自動化 ≠ 無人值守：關鍵路徑（如從庫上線拉 Binlog）必須有人工把關
2. 流程固化 > 工具修補：禁用自啟 + 變更單 + 人工確認，成本最低、效果最好
3. 監控要看「導向指標」：網卡流量、復制積壓、實例存活，而非只看 CPU/MEM

將此案例寫入《MySQL 運維避坑指南》，每次從庫上架/重啟必讀、必核、必簽。