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 % 的性能损耗，因此建议，打开需要的统计。