Mysql 系列之：如何正確地對 Mysql 實例做健康檢查

問題

1. select 1 做節點健康檢查有啥問題？
2. 如何正確地做實例監控檢查？

Mysql 高可用架構

Mysql 的 HA 架構包括一主一備、雙主、一主一備多從。既然是高可用，必然涉及切換。

主備切換包括兩種場景

1. 主動切換：一般爲計劃內的切換，需要升級，降級等各種情況
2. 被動切換：一般爲異常導致節點切換。由 HA 系統發起。

那麼，Mysql 檢查節點異常的正確姿勢是啥呢？

常用的的檢查 mysql 的方法是

select  1 

，那麼，這樣做有哪些問題，正確如何做呢？

異常情況

情況一、由於併發線程數達到上限，真正查詢請求無法處理。

併發線程數由參數 innodb_thread_concurrency 決定。 但 select 1 這樣的請求不會阻塞。解決辦法就是在數據庫建一張表 health_check，通過查詢來檢查。

情況二、由於磁盤空間耗盡，所有的更新和事務提交操作不可用，但是數據查詢還是可用的。

情況三、由於是高可用架構，區分不同節點的檢測

情況四、判斷不夠及時

解決辦法：

對於情況一和二：採用如下方法

創建一張表，以 service_id 爲主鍵，不同節點執行不同的更新

CREATE TABLE `health_check` (  `id` int(11) NOT NULL,  `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,  PRIMARY KEY (`id`)) ENGINE=InnoDB;

insert into mysql.health_check(id, t_modified) values (@@server_id, now()) on duplicate key update t_modified=now();

對於情況三：

select event_name,MAX_TIMER_WAIT  FROM performance_schema.file_summary_by_event_name where event_name in ('wait/io/file/innodb/innodb_log_file','wait/io/file/sql/binlog') and MAX_TIMER_WAIT>200*1000000000;


truncate table performance_schema.file_summary_by_event_name;

如何正確配置，參考附錄。

總結

Mysql 如何監控節點的監控的點，你 get 到了麼？

附錄

開啓 redo log 監控

# 查詢 redo log 統計開關是否打開
select * from performance_schema.setup_instruments where name like '%wait/io/file/innodb/innodb_log_file%';
# 開啓 redo log
update performance_schema.setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/innodb/innodb_log_file%'

# 查詢 redo log 統計信息
select * from performance_schema.file_summary_by_event_name where event_name = 'wait/io/file/innodb/innodb_log_file';

開啓 binlog 監控

# 查詢 binlog 統計開關是否開啓
select * from performance_schema.setup_instruments where name like '%wait/io/file/sql/binlog%';

# 開啓 binlog
update performance_schema.setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/sql/binlog%'

# 查詢 binlog 統計信息
select * from performance_schema.file_summary_by_event_name where event_name = 'wait/io/file/sql/binlog';

注：打開 performance_schema 全部的統計，大約有 10 % 的性能損耗，因此建議，打開需要的統計。