共计 1190 个字符，预计需要花费 3 分钟才能阅读完成。
作者：岳明强
爱可生北京分公司 DBA 团队成员，负责数据库治理平台的运维和 MySQL 问题解决。善于对 MySQL 的故障定位。
本文起源：原创投稿
* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。
在生产中个别产生运行问题，能够翻翻 error 日志，大部分都能解决。有的时候数据库忽然宕机重启，此时咱们在 error 日志中会发现 ”This could be because you hit a bug”，而后打了一堆看不懂的堆栈。这时候如果拿着碰到 BUG 的论断交差，多半会被利用一顿暴击输入：有证据没，这个 bug 怎么呈现的，官网怎么修的，在什么版本修的。那么接下来，我将依据现有 error 日志报错中的堆栈信息，找到具体的 BUG 修复记录
一、查看以后谬误日志
MySQL 异样解体，查看 error 日志，红框处为地位信息
注：如呈现这种相似 BUG 信息，不应只看这部分信息，应先查看 MySQL 异样退出前是否存在报错信息。此处不进行演示
二、gdb 查看报错文件地位
应用 gdb 追踪报错文件地位，后面报错文件为 mysqld , 就 gdb mysqld 文件，如果是其余的文件，例如组复制插件，那么就 gdb 该文件
首先先 b 一下函数名称，如下所示：
能够看出前面找到两个地位，而后咱们再加上偏移量，再 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 时并没有对该段代码进行间接批改时，可能会生效，这时候须要对堆栈指向的代码进行梳理，搞清楚这部分逻辑，再剖析。
