如何判断主库的健康

如何判断主库的健康

select 1:说明进程还在,但是不能说明主库没问题

- 有可能被占满了,设置innodb_thread_concurrency控制innodb的并发线程上限,并发连接如果线程的查询进入等待,则并发连接的计数会-1,所以使用select 1可能线程已经超过innodb_thread_concurrency,全被阻塞住了,但是select 1可用

查表判断:

mysql> select * from mysql.health_check; 

• 空间满了,binlog在写数据写不了,所有的更新和新增操作都会被阻塞,所以只用查询是不能保证的

更新判断

mysql> update mysql.health_check set t_modified=now();

• 在主备的情况下,要保证主备都能做修改,所以都要执行修改操作,但是会有一个判定慢的问题
• 也就是说在日志盘满的情况下,刚好幸运的执行了update的语句,所以有可能在需要主备切换的情况下,刚好执行了update,返回了正常的情况,下一秒就不行了

内部操作

• 在5.6版本下,performance_schema库下的file_summary_by_event_name表统计了io请求的时间,开启performance_schema会有百分之10的损耗,可以通过下面的sql开启某些具体项的统计

mysql> update setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/innodb/innodb_log_file%';
//打开redo log的时间监控

mysql> 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;
//通过max_time的值来判断,上面这个sql就是单次io超过200毫秒的异常数据

取到之后,需要清除刚才统计的信息

mysql> truncate table performance_schema.file_summary_by_event_name;