一主一备的双 M 架构里，客户端流量切到备库；主多从，还需要把从库接到新主库上。
两种场景，主动，被动切换。主库出问题 HA 系统发起。
一、select 1 判断
1.1innodb_thread_concurrency 并发线程上限（
建议64~128
）
=3 个线程并行执行。三个 session 中sleep(100)三个语句都“执行”状态，模拟大查询
select 1成功（检测不出问题），t 被堵住
=0，不限制。不行：CPU 核数有限，线程全来，上下文切换成本高。
并发连接：show processlist 几千个连接（影响不大，占内存）。
并发查询：“当前正在执行”，CPU 杀手。
第 7 篇文章热点更新和死锁检测的时候， 128 热点更消耗完了，系统是不是就挂了？
线程进入锁等待以后，并发线程的计数会减一，等行锁（也包括间隙锁）线程是不算 128 里，不吃 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. 线程计数不减一，用满阻止其他执行， 1 不能提交。另外128 等待，堵住（占用 CPU 0，不合理）
锁等待，并发线程计数减 1 必要的
等锁线程不算并发线程计数里， select sleep(100) from t 算
二、查表判断
创建表 health_check定期执行：mysql> select * from mysql.health_check;
检测并发线程过多导致不可用，空间满不好使。
binlog 占用率100%，更新和 commit 堵住。正常读。
三、更新判断
主、备库放 timestamp （最后一次执行检测时间）mysql> update mysql.health_check set t_modified=now();
备库检测也写 binlog 。双 M 结构，B 上执行检测命令，发回给主库 A。
AB相同更新命令，行冲突，主备同步停止。mysql.health_check要存多行， A、B server_id 做主键。
insert into mysql.health_check(id, t_modified) values (@@server_id, now()) on duplicate key update t_modified=now();
主库和备库的 server_id 必须不同（否则创建主备关系报错），保证检测不冲突。
更新语句，失败或者超时，发起主备切换了，为什么会判定慢？
IO 资源分配问题：
如果update 超过 N （超时时间）不返回，判定系统不可用。
场景：IO 利用率100% 。响应非常慢，需要主备切换。但update 需资源少，提交成功， N 秒未到达之前返回
结果：判定正常（不准确），update 没有超时，正常SQL慢，HA 系统正常
不准确原因：基于外部检测，随机性。定时轮询，第一次轮询还不能发现，切换慢
四、内部统计
内部每次 IO 请求时间：performance_schema 库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_NUMBER_OF_BYTES_READ 总共从 redo log 里读了多少个字节。
第三组六列，统计写操作。
最后第四组数据，其他类型数据统计。redo log 对 fsync 的统计。
binlog 对应 event_name = "wait/io/file/sql/binlog"与 redo log 各个字段完全相同。
performance_schema额外统计，性能损耗（打开所有下降 10% 左右）。
redo log 时间监控：
mysql> 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 毫秒异常，
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;
发现异常：mysql> truncate table performance_schema.file_summary_by_event_name;
清空统计信息。再次出现，加入监控累积值。
小结
MySQL 检测健康几种方法，各种问题和演进逻辑。
select 1是不是已被淘汰，实际使用非常广泛 MHA（Master High Availability）默认方法
MHA 中另可选方法：只做连接（很少），“连接成功，主库没问题”。
改进方案，增加额外损耗，实际情况做权衡。
优先考虑 update 系统表，配合增加检测performance_schema
开发和维护中，怎么判断服务有没有问题？
评论1
一台服务器update方式。主从架构一条语句,双主两条update。弊端,单点判断。超半监控进程认为出问题,才切
1.innodb_thread_concurrency跟计算机核数成正比,2倍最好.创建虚拟机分1~2个核，设置成4
2.空间满了,连接都连不上,更不用select,这个是什么原因啊？
空间满本身不会导致连不上。但空间满，无法提交，接外部重试（堵在提交），持续累积把连接数用满
评论2
dubbo 存活检测三个层面
（1）服务端与注册中心（zookeeper）链接状态
服务端注册临时节点，客户端注册这个节点watch事件，一但服务端失联，客户端移除该服务（多个提供者，只移除失联）。
zookeeper心跳发现失联，固定频率（比如每秒）发送检测数据包；
（2）客户端与注册中心的链接状态
客户端与zookeeper失联，用缓存服务提供者列表。多次调不通移除。
（3）客户端与服务端的链接状态
定时调用。亚健康状态，超过阀值，降级
移除一定时间后重试，恢复或继续降级。
状态监控，用外部系统；质量监控，接口响应时间来统计
评论3
1.基础监控，硬盘，CPU，网络，内存等。
2.服务监控，包括jvm，服务端口，接入上下游服务的超时监控等。
3.业务监控，监控业务流程是否出现问题。
