MySQL系列~异常宕机

异常宕机汇总

一、能自行启动的异常宕机

此类宕机事件通常与MySQL的某些特性或资源争用有关，以下是遇到过的案例及解决办法。

案例1：MySQL特性引起的宕机

核心报错信息表明，存在长时间的semaphore等待，超过600秒后触发断言失败，导致服务崩溃。这种情况可能由以下原因造成：

自适应哈希索引（AHI）导致的latch争用。
慢查询或大事务长时间占用RW-latch锁，导致其他事务阻塞。
解决办法：

尝试关闭自适应哈希索引：set global innodb_adaptive_hash_index=0;，并持续观察。
根据show innodb status的记录分析并优化查询语句和事务。
案例2：特定查询导致的宕机

执行特定表的特定查询语句时MySQL重启。其他查询和在其他从库上执行相同查询均无问题。

解决办法：

联系开发改造特定查询SQL作为临时解决方案。
关闭loosescan优化特性可避免此问题，此参数影响semi-join的优化。
总结：

对于此类由BUG或特性导致的宕机，通常的解决方法是定位到具体参数并关闭它，而不必立即进行版本升级。

二、无法启动的异常宕机

这类宕机通常与InnoDB存储引擎的基本页损坏或日志文件不一致有关。

案例1：redo page损坏

报错日志显示页的日志序列号在未来，指示redo page可能已损坏。

解决办法：

调整InnoDB的恢复级别进行数据拯救。

案例2：表的index page损坏

报错指出表的索引页损坏，导致操作失败。

解决办法：

调整隔离级别为1以禁用损坏检测。
备份数据并删除原表。
总结：

页损坏的原因可能包括硬件问题、驱动程序错误、内核错误、电源故障或罕见的MySQL bug。
调整恢复级别前应先备份数据，因为高级别的恢复可能对数据产生更大影响。
三、可启动但可能是产品BUG导致的异常

包括与Linux AIO接口相关的问题、InnoDB页损坏的断言失败等。

解决办法：

升级到修复了相关BUG的MySQL版本。
使用innodbchecksum工具定位并修复损坏的页。
总结：

准备好与线上版本相对应的MySQL源码包，以便在出现BUG时能够查询具体的CC代码内容。
关注如taobao.mysql等资源，以获取对MySQL源码的深入解读和可能的解决方案。