故障分析 | 数据库故障 MHA 未切换

某天晚上，数据库 hang 住，现象是：

无奈之下通过强制 kill 掉进程，重启数据库恢复。

这里暂且不说 hang 住的原因，仅分析数据库 hang 住，但是 MHA 未触发切换。

先说下结论，MHA 默认使用长连接对数据库做 ping 健康 检测（执行 select 1 as Value ），4次无法连接 MySQL 则触发切换。 前面数据库 hang 住只是新的连接无法建立，但是老连接却没有影响，且 MHA 的 健康 检测语句很简单，只在 server 层进行了检测，不涉及到 InnoDB 层，所以 MHA 认为 MySQL 是 健康 的，并没有作出任何决策。

MHA 从 0.53 版本开始支持 ping_type 参数设置如何检查 master 的可用性。支持3个 value ：

通过将 ping_type 修改设置为 connect ，MHA 每次进程状态检测，需要新建连接，新链接无法成功建立，就触发了切换。

三种检测机制代码：

MHA 配置文件

模拟服务器CPU满负载，数据库无法建立新连接 编写一个简单的c程序，如下：

编译：

执行：

另外再跑两个 mysqlslap 压测程序：

有兴趣的同学可自行测试一下

调用链路：

MHA 监控进程启动后，会持续监控主节点的状态，主要的 健康 检测函数是 wait_until_unreachable()。

在这个函数中会有一个死循环，持续地进行 健康 检测

1.首先，测试连接，连接正确返回0，否则返回1。

2.测试连接成功后，则进行 健康 状态检测（前面说的3种方式）；如果连续4次连接失败，则在第4次的时候会使用第二脚本进行检测（如果定义了的话），如果检测通过，则认为 master 挂掉

关键函数 wait_until_unreachable()代码：

数据库运行过程中常见的故障有3类：事物故障、系统故障、介质故障。

恢复策略：

1、事物故障：

发生事务故障时，被迫中断的事务可能已对数据库进行丁修改，为了消除该事务对数据库的影响，要利用日志文件中所记载的信息，强行回滚该事务，将数据库恢复到修改前的初始状态。

为此，要检查日志文件中由这些事务所引起的发生变化的记录，取消这些没有完成的事务所做的一切改变，这类恢复 *** 作称为事务撤销。

2、系统故障：

系统故障的恢复要完成两方面的工作，既要撤销所有末完成的事务，还要重做所有已提交的事务，这样才能将数据库真正恢复到一致的状态。

3、介质故障：

介质故障比事务故障和系统故障发生的可能性要小，但这是最严重的一种故障，破坏性很大，磁盘上的物理数据和日志文件可能被破坏，这需要装入发生介质故障前最新的后备数据库副本，然后利用日志文件重做该副本后所运行的所有事务。

扩展资料：

“数据故障恢复”和“完整性约束”、“并发控制”一样，都是数据库数据保护机制中的一种完整性控制。所有的系统都免不了会发生故障，有可能是硬件失灵，有可能是软件系统崩溃，也有可能是其他外界的原因，比如断电等等。

数据库运行的突然中断会使数据库处在一个错误的状态，而且故障排除后没有办法让系统精确地从断点继续执行下去。这就要求DBMS要有一套故障后的数据恢复机构，保证数据库能够回复到一致的、正确地状态去。

参考资料来源：百度百科-事务故障

参考资料来源：百度百科-系统故障

参考资料来源：百度百科-介质故障

---