MySQL slave_net_timeout 參數調優：解決 5.6 升級後頻繁重連 Warning 案例

故障背景

集群從 5.5 升級至 5.6 後，error.log 狂刷 Warning：

[Warning] Storing MySQL user name or password information in the master info repository is not secure...

業務極低峰期 QPS≈1，TPS≈0，寫入間隔 4-10 秒甚至更久。

根因分析：5.6 安全增強 + 低流量觸發重連風暴

1. 5.6 安全機制：不建議在 CHANGE MASTER TO 中明文指定密碼。若搭建主從時帶了密碼，5.6 會在每次重連時記錄此 Warning。
2. 重連機制：Slave IO 線程若在 slave_net_timeout 秒內未收到 Master 的 Binlog Event，會主動發起重連。默認值 3600 秒，但許多環境調為 5 秒左右以快速發現異常。
3. 低流量放大效應：業務 10 秒才一筆寫入，Master 10 秒無 Binlog 事件 → Slave 判定超時 → 發起重連 → 記錄 Warning → 循環往複，Error.log 被刷爆。

解決方案

方案一：調大 slave_net_timeout（推薦）

SET GLOBAL slave_net_timeout = 25;  -- 設為 25 秒，覆蓋業務最大寫入間隔

線上建議值：10-30 秒，平衡故障發現速度與誤判率。

方案二：業務層面優化（治本）

• 與業務方溝通，評估極低流量業務是否可下線，釋放資源。
• 若必須保留，考慮定時發送心跳事件（如 INSERT INTO heartbeat ...）保持連接活躍。

方案三：修正 CHANGE MASTER 寫法（消除 Warning 根源）

-- 5.6+ 推薦：不在 CHANGE MASTER 中指定密碼
CHANGE MASTER TO MASTER_HOST='x', MASTER_USER='repl', MASTER_PASSWORD='';  -- 空密碼
-- 搭配 ~/.my.cnf 或 MYSQL_PWD 環境變數提供密碼

參數速查表

核心啟示

參數調優必須結合業務流量特徵。低寫入頻率系統盲目套用「快速故障發現」的小超時值，反而製造虛假告警與重連風暴。觀測業務寫入間隔分佈（P99/P999），設定 slave_net_timeout > Max_Write_Interval 才是科學做法。