MySQL 實例 Hang 住檢測與自動切換方案

Hang 住的典型癥狀

• 只能查詢，無法執行 DML（INSERT/UPDATE/DELETE）
• 僅能查系統庫或 information_schema，業務庫無響應
• SHOW PROCESSLIST 可執行但所有線程狀態凍結
• 甚至 SHOW PROCESSLIST 也卡住，僅 SHOW STATUS 等輕量命令可用
• 進程存活、端口通達，但負載驟降至 0，CPU/IO 閒置

常見檢測手段的盲區

ping/telnet 只能檢測進程與網絡；SHOW/SELECT 查詢在 Hang 早期可能仍能成功，無法反映寫入阻塞。

推薦：基於寫入探測的分級檢測機制

探測表結構

CREATE TABLE monitor_db (
  ID SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
  CreateDate TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (ID)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO monitor_db VALUES (1, NOW()), (2, DATE_SUB(NOW(), INTERVAL 1 DAY));

探測 SQL（避免雙主復制衝突）

-- MySQL 5.0 及以下
UPDATE monitor_db SET CreateDate = NOW() WHERE ID = 1;

-- MySQL 5.1+ （不寫入 Binlog）
SET SESSION sql_log_bin = 0;
UPDATE monitor_db SET CreateDate = NOW() WHERE ID = 1;

三級探測邏輯

1. 常規探測：每 10 秒執行一次 UPDATE。
2. 快速複核：首次失敗後，每 1 秒連續探測 2 次。
3. 最終確認：仍失敗則每 5 毫秒探測 3 次，全部失敗判定為不可用，觸發主備切換。

恢復建議

Hang 後正常關閉無效，需 OS 層面 kill -9 進程後重啟，待 InnoDB 自動回滾完成。避免使用 5.0.82 等已知 Bug 版本。