在实际的应用中,其实大多数是主从结构。而采用主备,一般都需要一定的费用。
对于主备,如果主机故障,那么只需要直接将流量打到备机就可以,但是对于一主多从,还需要将从库连接到主库上。
对于切换的操作,一种是主动切换,(人为升级配置),另一种是被动切换,(主机故障)。那么如何判断一个数据库是否出问题。
select 1 判断
set global innodb_thread_concurrency=1;
session A | session B |
---|---|
select sleep(100) from T; | select 1; |
select * from T; |
innodb_thread_concurrency
控制InnoDB的并发线程上限,达到这个值,InnoDB在接受新的请求,就会进入等待状态,直到有退出的线程,才会执行。
我们讲 innodb_thread_concurrency
设置为1,然后session A就阻塞,然后在执行session B中的 select 1 ,发现正常返回结果,1,但是如果查询表T 发现被阻塞了。所以select 1 只能表示数据库进程还在,但是检测不出问题。
并发连接和并发查询
innodb_thread_concurrency
默认参数是0,表示不限制并发连接数。一般并发数会受到操作系统底层的线程。建议设置在 64-128之间。 那么可能有人会想,128并发连接数是不是有点低。因为对于大型互联网应用来说,动辄都是秒级别的上万流量。
其实并发连接和并发查询不是同一个事情,并发连接是客户端和服务端建立了连接,多占用内存。也就是通过 show processlist
, 而并发查询是当前正在执行的语句。
那么处于锁等待的线程是否占用并发线程的计数,其实是不占用的,因为锁等待的线程是不占用CPU,没有必要占用。
查表判断
为了避免因并发线程数过多而导致的系统不可用,可以创建一张health_check 里放一条数据。然后定期执行。
select * from mysql.health_check;
但是,如果bin log的磁盘满了,那么就会导致无法更新语句,但是可以正常读取。之前在生产的时候就遇到过,磁盘满,查询语句可以执行,但是更新语句无法执行。
更新判断
update mysql.health_check set t_modified=now();
既然要更新,那么可以采用时间做处理,但是针对主从库检测的话,如果同步修改从库,那么就会出现行冲突,从库即接受主库的bin log,也接受自己的更新。所以可以采用多条数据。
mysql> 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();
但是这种方式其实有一定的随机性,那就是IO利用率已经100%。可能我们执行的update语句很快执行完毕,在超时时间内返回的,那么我们就无法检测出系统是否故障。
内部统计
当然我们可以采用 performance_schema 库本身的 redo log的时间统计。
总结
其实对于数据库来说,推荐使用 更新语句+内部统计的方式,其实不仅仅对于数据库来说,对于业务系统来说,需要保证服务高可用,而目前所在公司的方案是采用SLB+健康检查接口进行判断服务是否高可用。弊端的话 其实没有办法检测服务异常,只能检测服务进程是否宕机。