您现在的位置：程式碼之家 >> 數據庫知識 > >> MySQL 資料庫 >> MySQL 資料庫相關知識

MySQL slave_net_timeout 參數調優：解決低寫入場景下從庫頻繁重連告警

編輯：MySQL 資料庫相關知識

MySQL 5.5 升級 5.6 後，error.log 狂刷 Warning：Storing MySQL user name or password information in the master info repository is not secure...。業務極低寫入 (QPS 1, TPS ~0，4-10 秒才有一筆寫入)，從庫頻繁發起重連，導致日誌暴增、監控誤報。根因在於 slave_net_timeout 默認值 (5.6 默認 60 秒，舊版 3600 秒) 與低寫入間隔不匹配。本文詳細分析重連機制並給出調優方案。

背景與現象

升級路徑：MySQL 5.5 → 5.6
業務特徵：極低寫入頻率，Binlog 產生間隔遠大於 slave_net_timeout

錯誤日誌：

2015-02-03 15:44:51 19633 [Warning] Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider using the USER and PASSWORD connection options for START SLAVE...

核心機制深度解析

1. 主從複寫信息存儲變更 (5.6 安全增強)

5.5：master.info 明文存儲 MASTER_USER, MASTER_PASSWORD。
5.6：不建議在 CHANGE MASTER TO 中指定密碼，改用 START SLAVE USER='...' PASSWORD='...' 語法。若檢測到明文密碼，每次重連/啟動 Slave 時都會打印上述 Warning。

2. Slave IO Thread 重連邏輯

Slave IO Thread 與 Master 建立連接後，發送 COM_BINLOG_DUMP 請求 Binlog 事件。若超過 slave_net_timeout 秒未收到任何數據包 (含 Heartbeat)，Slave 判定連接超時，主動發起重連。

重連時需重新認證 → 讀取 master.info / slave_master_info 表中的憑證 → 檢測到明文密碼 → **打印 Warning**。
低寫入場景：Master 長時間無 Binlog 事件 → 超時觸發重連 → 循環往複。

3. slave_net_timeout 參數演進

解決方案

方案一：調大 slave_net_timeout (推薦快速止血)

根據業務寫入間隔，設定為 **最大預期間隔的 2-3 倍** 。本案例寫入間隔 10 秒，設為 25 秒 即可避免誤判超時。

-- 動態生效 (無需重啟)
SET GLOBAL slave_net_timeout = 25;

-- 永久生效 (my.cnf)
[mysqld]
slave_net_timeout = 25

注意：設值過大 (如默認 3600) 會導致真實網路故障檢測延遲，延長 RTO。生產環境建議 **5-30 秒** 區間，配合心跳機制。

方案二：啟用 Master Heartbeat (標準做法)

MySQL 5.5+ 支援 MASTER_HEARTBEAT_PERIOD (單位：秒，精度毫秒)。Master 在無 Binlog 時定期發送心跳包，Slave 收到心跳即重置超時計時器，**不依賴業務寫入頻率**。

-- 在 Slave 上執行 (需停止 Slave)
STOP SLAVE;
CHANGE MASTER TO MASTER_HEARTBEAT_PERIOD = 10;  -- 每 10 秒發送心跳
START SLAVE;

最佳實踐：MASTER_HEARTBEAT_PERIOD < slave_net_timeout / 2 (如 timeout=25, heartbeat=10)，確保心跳能在超時前到達。

方案三：消除明文密碼 Warning (根治)

使用 5.6 推薦語法重新建立複寫關係：

STOP SLAVE;
CHANGE MASTER TO
  MASTER_HOST='...',
  MASTER_PORT=3306,
  MASTER_USER='repl_user',
  MASTER_PASSWORD='',  -- 此處留空
  MASTER_LOG_FILE='...',
  MASTER_LOG_POS=...,
  MASTER_HEARTBEAT_PERIOD=10;
START SLAVE USER='repl_user' PASSWORD='real_password';  -- 密碼在這裡傳遞，不持久化

或升級至 MySQL 5.7+ 使用 CHANGE MASTER TO MASTER_PASSWORD='...' (加密存儲於 slave_master_info 表)。

方案四：業務層面優化 (源頭治理)

評估該業務是否仍需維護：極低寫入、無實時性要求 → **下線/歸檔/遷移至輕量級存儲 (SQLite/CSV/Redis)**，釋放資源。
若必須保留：考慮定期 FLUSH LOGS 產生 Binlog 事件 (如每分鐘 cron)，但屬於治標不治本。

參數調優決策樹

業務寫入間隔 < 10 秒 → 保持默認 60 秒，啟用 Heartbeat (10-30 秒)。
業務寫入間隔 10-60 秒 → slave_net_timeout = 最大間隔 * 2，啟用 Heartbeat。
業務寫入間隔 > 60 秒 (極低寫入) → **方案三 + 方案四** (消除密碼 Warning + 評估下線) 或設 slave_net_timeout = 300 (5 分鐘) + Heartbeat 60 秒。

驗證與監控

SHOW SLAVE STATUS\G 觀察 Slave_IO_Running: Yes、Seconds_Behind_Master: 0、Master_Heartbeat_Period。
監控 Slave_IO_Running 狀態變更次數 (Prometheus/Grafana)，重連頻率應歸零。
error.log 不再刷新明文密碼 Warning。

總結：**slave_net_timeout 不是越小越好**，需匹配業務寫入特徵。**Heartbeat 機制是解決低寫入場景超時重連的標準答案**，配合 5.6+ 安全密碼管理，徹底消除誤報與日誌噪音。