技术分享 | 如何根据 MySQL 崩溃日志找到已修复的 BUG 内容
作者:岳明强在生产中一般发生运行问题,可以翻翻 error 日志,大部分都能解决。有的时候数据库突然宕机重启,此时我们在 error 日志中会发现"This could be because you hit a bug",然后打了一堆看不懂的堆栈。这时候如果拿着碰到BUG的结论交差,多半会被应用一顿暴击输出:有证据没,这个 bug 怎么出现的,官方怎么修的,在什么版本修的。那么接下来,我将根据现有 error 日志报错中的堆栈信息,找到详细的 BUG 修复记录
爱可生北京分公司 DBA 团队成员,负责数据库管理平台的运维和 MySQL 问题处理。擅长对 MySQL 的故障定位。
本文来源:原创投稿
*爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。
一、查看当前错误日志 MySQL 异常崩溃,查看 error 日志,红框处为位置信息
注:如出现这种类似 BUG 信息,不应只看这部分信息,应先查看 MySQL 异常退出前是否存在报错信息。此处不进行演示
文章图片
二、gdb 查看报错文件位置 使用 gdb 追踪报错文件位置,前面报错文件为 mysqld ,就 gdb mysqld 文件,如果是其他的文件,例如组复制插件,那么就 gdb 该文件
首先先 b 一下函数名称,如下所示:
文章图片
【技术分享 | 如何根据 MySQL 崩溃日志找到已修复的 BUG 内容】可以看出后面找到两个位置,然后我们再加上偏移量,再 b 一下:
文章图片
很明显,第二个找到的是 mysql 里文件,从官方上下载相同版本源码包进行解压,找过 pipeline_stats.h 这一文件中的410行,确定函数名为 Pipeline_member_stats()
文章图片
三、查看该函数变更内容 在 github上mysql 官方地址中找到这一文件
https://github.com/mysql/mysq...
文章图片
搜索相应的关键字到该位置
文章图片
网址上默认为8.0最新版本的代码,取下来和8.0.18版本的代码进行对比
文章图片
四、查看变更内容历史 通过对比工具,可以看出该段函数代码,存在部分的更改,接下来,再看看变更这部分代码的原因,打开左侧的 Blame ,可以看出历史的变更记录
文章图片
文章图片
文章图片
该函数内大部分的变更都是由于 Bug#30049349 引起,可以进去看看 bug 详细的内容,文章中指出 stop group_replication 时,进行P_S查看有几率造成数据库 crash,修复的方式是在 stop group_replication 的时候,给P_S中的相关表加一个读写锁,禁止查询
文章图片
在 MySQL 官网的 Release Notes 里也能找到是在8.0.20版本修复该bug
文章图片
还可以从整个文件的 History 中查看历史更改
文章图片
五、结语 文章内主要提到通过 error 日志找到当前已经修复的 bug 。碰到 error 日志中有上述报错,应该先对崩溃前的报错进行分析,部分的崩溃报错不用通过堆栈的方式定位就能找到问题。如碰到目前还未修复或者修复 bug 时并没有对该段代码进行直接修改时,可能会失效,这时候需要对堆栈指向的代码进行梳理,搞清楚这部分逻辑,再分析。
推荐阅读
- 第326天
- 考研英语阅读终极解决方案——阅读理解如何巧拿高分
- 如何寻找情感问答App的分析切入点
- mybatisplus如何在xml的连表查询中使用queryWrapper
- MybatisPlus使用queryWrapper如何实现复杂查询
- 如何在Mac中的文件选择框中打开系统隐藏文件夹
- 漫画初学者如何学习漫画背景的透视画法(这篇教程请收藏好了!)
- java中如何实现重建二叉树
- Linux下面如何查看tomcat已经使用多少线程
- thinkphp|thinkphp 3.2 如何调用第三方类库