MySQL主从复制（六）：数据库是否可用

select 1判断

场景示例：

-- 设置innodb并发度为3，从而限制并发查询
set global innodb_thread_concurrency=3;

-- 创建表t
CREATE TABLE `t` (
 `id` int(11) NOT NULL,
 `c` int(11) DEFAULT NULL,
 PRIMARY KEY (`id`)
) ENGINE=InnoDB;

-- 插入1行数据 insert into t values(1,1)
insert into t values(1,1);

查询blocked：

设置innodb_thread_concurrency参数的目的是，控制InnoDB的并发线程上限。也就是说，一旦并发线程数达到这个值， InnoDB在接收到新请求的时候，就会进入等待状态，直到有线程退出。

上图中，前三个session 中的sleep(100)，使得这三个语句都处于“执行”状态，以此来模拟大查询。

session D里面， select 1是能执行成功的，但是查询表t的语句会被堵住。也就是说，如果这时候我们用select 1来检测实例是否正常的话，是检测不出问题的。

通常情况下，建议把innodb_thread_concurrency设置为64~128之间的值。

问1：并发线程数设置为128够干啥，线上的并发连接数动不动就上千了？

答：产生这个疑问的原因，是搞混了并发连接和并发查询。

并发连接和并发查询，并不是同一个概念。你在show processlist的结果里，看到的几千个连接，指的就是并发连接。而“当前正在执行”的语句，才是我们所说的并发查询。

并发连接数达到几千个影响并不大，就是多占一些内存而已。我们应该关注的是并发查询，因为并发查询太高才是CPU杀手。这也是为什么我们需要设置innodb_thread_concurrency参数的原因。

问2：如果把innodb_thread_concurrency设置为128的话，那么出现同一行热点更新的问题时，是不是很快就把128消耗完了，这样整个系统是不是就挂了呢？

答：在线程进入锁等待以后，并发线程的计数会减一，也就是说等行锁（也包括间隙锁）的线程是不算在128里面的。MySQL这样设计是非常有意义的。因为，进入锁等待的线程已经不吃CPU了。

问3：为什么进入锁等待的线程不吃CPU可以避免整个系统锁死？

答：假设处于锁等待的线程也占并发线程的计数，可以设想一下这个场景：

1）线程1执行begin; update t set c=c+1 where id=1, 启动了事务trx1，然后保持这个状态。这时候，线程处于空闲状态，不算在并发线程里面。

2）线程2到线程129都执行 update t set c=c+1 where id=1; 由于等行锁，进入等待状态。这样就有128个线程处于等待状态。

3）如果处于锁等待状态的线程计数不减一， InnoDB就会认为线程数用满了，会阻止其他语句进入引擎执行（包括commit），这样线程1不能提交事务。而另外的128个线程又处于锁等待状态，整个系统就堵住了。

系统锁死状态图：

这时候InnoDB不能响应任何请求，整个系统被锁死。而且，由于所有线程都处于等待状态，此时占用的CPU却是0，而这明显不合理。所以，我们说InnoDB在设计时，遇到进程进入锁等待的情况时，将并发线程的计数减1的设计，是合理而且是必要的。

注：虽然说等锁的线程不算在并发线程计数里，但如果它在真正地执行查询，就比如我们上面例子中前三个事务中的select sleep(100) from t，还是要算进并发线程的计数的。

因此上述select 1示例中，同时在执行的语句超过了设置的innodb_thread_concurrency的值，这时候系统其实已经不行了，但是通过select 1来检测系统，会认为系统还是正常的。

总结：

Select 1判断：定期执行select 1成功返回，表示DB是连通的。
使用场景：主要用于检测MySQL连通性。
存在问题：不完善，如果使用select 1检测DB的可用性，可能出现DB连接畅通，但引擎层并发压力已达上限，导致DB不可用。
解决办法：使用查表判断方案可解决该问题。

查表判断

为了能够检测InnoDB并发线程数过多导致的系统不可用情况，我们需要找一个访问InnoDB的场景。一般的做法是，在系统库（mysql库）里创建一个表，比如命名为health_check，里面只放一行数据，然后定期执行：

select * from mysql.health_check;

使用这个方法，我们可以检测出由于并发线程过多导致的数据库不可用的情况。

问：如果空间满了，使用该方法检测数据库是否可用，是否有问题？

答：更新事务要写binlog，而一旦binlog所在磁盘的空间占用率达到100%，那么所有的更新语句和事务提交的commit语句就都会被堵住。但是，系统这时候还是可以正常读数据的。也就是说，此时该方法无法检测数据库是否是可用的。

因此，需要把查询语句改为更新语句。

总结：

查表判断：在系统库（mysql库）里创建一个表，如health_check，插入一行数据，定期执行查询语句：select * from mysql.health_check;
使用场景：能够检测InnoDB并发线程数过多导致的系统不可用情况。
存在问题：不完善，磁盘问题无法检测到，可能读请求正常，但写请求已阻塞；比如：写binlog，磁盘满了以后，所有事务更新语句都被阻塞；但读请求正常。此时无法检测到DB不可用。
解决方案：使用更新判断方案可解决该问题。

更新判断（推荐使用）

既然要更新，就要放个有意义的字段，常见做法是放一个timestamp字段，用来表示最后一次执行检测的时间。这条更新语句类似于：

update mysql.health_check set t_modified=now();

注1：节点可用性的检测应该包含主库和备库。如果用更新来检测主库的话，那么备库也要进行更新检测。

注2：对于双M结构（A、B互为主备），由于备库B也要写binlog，如果主库A和备库B都用相同的更新命令，则可能出现行冲突，即可能导致主备同步停止。因此mysql.health_check 这个表就不能只有一行数据了。

为了让主备之间的更新不产生冲突，我们可以在mysql.health_check表上存入多行数据，并用A、 B的server_id做主键。

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

-- 检测命令
insert into mysql.health_check(id, t_modified) values (@@server_id, now()) onduplicate key update t_modified=now();

由于MySQL规定了主库和备库的server_id必须不同，这样就可以保证主、备库各自的检测命令不会发生冲突。

虽然该方案是比较常用的一种方案，但仍存在“判定慢”问题。

问：更新语句，如果失败或者超时，就可以发起主备切换了，为什么还会有判定慢的问题呢？

这个问题主要涉及的是服务器IO资源分配问题。

所有的检测逻辑都需要一个超时时间N。执行一条update语句，超过N秒后还不返回，就认为系统不可用。

假设一个日志盘的IO利用率已经是100%的场景。这时候，整个系统响应非常慢，已经需要做主备切换了。而我们的检测使用的update命令，需要的资源很少，所以可能在拿到IO资源的时候就可以提交成功，并且在超时时间N秒未到达之前就返回给了检测系统。

检测系统一看， update命令没有超时，于是就得到了“系统正常”的结论。

之所以会出现这个现象，根本原因是我们上面说的所有方法，都是基于外部检测的。而外部检测天然有一个问题：随机性。

因为，外部检测都需要定时轮询，所以系统可能已经出问题了，但是却需要等到下一个检测发起执行语句的时候，才有可能发现问题。而且，如果你的运气不够好的话，可能第一次轮询还不能发现，这就会导致切换慢的问题。

总结：

更新判断：在系统库（mysql库）里创建一个表，如health_check，包含一个timestamp字段，表示最后一次执行检测的时间，插入一行数据，定期执行更新语句：update mysql.health_check set t_modified=now();
使用场景：能够检测InnoDB磁盘无法写入的情况。
存在问题：不完善，无法检测语句执行慢但不超时的场景；如磁盘IO打满，但仍然可以响应请求的场景。
解决方案：使用MySQL内部统计判断方案即可解决该问题。

内部统计（推荐使用）

MySQL 5.6版本以后提供的performance_schema库，在file_summary_by_event_name表里统计了每次IO请求的时间。

file_summary_by_event_name表里有很多行数据，我们先来看看event_name='wait/io/file/innodb/innodb_log_file’这一行。

图中这一行表示统计的是redo log的写入时间，第一列EVENT_NAME 表示统计的类型。

接下来的三组数据，显示的是redo log操作的时间统计：

第一组五列，是所有IO类型的统计。其中，COUNT_STAR是所有IO的总次数，接下来四列是具体的统计项，单位是皮秒；前缀SUM、 MIN、 AVG、 MAX，顾名思义指的就是总和、最小值、平均值和最大值。
第二组六列，是读操作的统计。最后一列SUM_NUMBER_OF_BYTES_READ统计的是，总共从redo log里读了多少个字节。
第三组六列，统计的是写操作。

最后的第四组数据，是对其他类型数据的统计。在redo log里，你可以认为它们就是对fsync的统计。

在performance_schema库的file_summary_by_event_name表里， binlog对应的是event_name = "wait/io/file/sql/binlog"这一行。各个字段的统计逻辑，与redo log的各个字段完全相同。

注1：因为我们每一次操作数据库， performance_schema都需要额外地统计这些信息，所以我们打开这个统计功能是有性能损耗的。

注2：如果打开所有的performance_schema项，性能大概会下降10%左右。所以，建议只打开自己需要的项进行统计。

打开或者关闭某个具体项的统计：如果要打开redo log和binlog的时间监控，你可以执行这个语句：

update setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/sql/binlog%';
update setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/innodb/innodb_log_file%';

问：假设，现在你已经开启了redo log和binlog这两个统计信息，那要怎么把这个信息用在实例状态诊断上呢？

答：可以通过MAX_TIMER的值来判断数据库是否出问题了。比如，你可以设定阈值，单次IO请求时间超过200毫秒属于异常，然后使用类似下面这条语句作为检测逻辑。

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;

把之前的统计信息清空。这样如果后面的监控中，再次出现这个异常，就可以加入监控累积值了。