故障分析 | MySQL 节点宕机分析一例

最新推荐文章于 2025-10-12 15:00:00 发布

原创

最新推荐文章于 2025-10-12 15:00:00 发布 · 561 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#并行读 #signal 6

本文介绍了一次 MySQL MGR 环境故障切换的排查过程，详细分析了错误日志信息，定位到 InnoDB 并行读取时发生的断言失败问题，并追溯到了具体的代码行。

作者：周启超

爱可生北分团队 DBA，主要负责项目前期建设及后期疑难问题支持。做事认真，对事负责。

本文来源：原创投稿

*爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

之前遇到一个问题，用户反馈 MySQL MGR 环境发生了故障切换。作为一名运维，首先应该知道从日志信息里面去找信息。我们很幸运，在对应的时间点，有错误日志信息。而且可以明确的是，切换原因就在这段错误日志信息当中。错误日志中堆栈信息如下：

2022-04-12T03:03:36.435579+08:00 0 [ERROR][MY-013183][InnoDB]Assertion failure: row0pread.cc:727:!page_cur_is_after_last(&page_cursor) thread 140441717634816 
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com. 
InnoDB: If you get repeated assertion failures or crashes, even 
InnoDB: immediately after the mysqld startup, there may be 
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html 
InnoDB:about forcing recovery.
19:03:36 UTC-mysqld got signal 6;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning h