MySQL Bug 的处理及修复

作为互联网领域应用最为广泛的数据库 MySQL，MySQL 在功能和性能等各方面都表现得非常出色，但在日常使用的过程中，我们也经常会遇到隐藏在 MySQL 各个模块的 Bug。

如果是在生产过程中遇到了 Bug，而且导致 MySQL 实例 crash 就可能会影响线上业务，所以，我们需要对 bug 进行及时修复，避免因其产生更严重的后果。

通常来说，我们遇到的 bug 都是 MySQL 官方在开发过程中引入的。

如果要修复，有以下两种情况： 如果有官方修复，而又不想升级到对应的官方修复版本，我们则需要找到对应的修复，通过打补丁的方式修复； 对于没有官方修复的 Bug，则需要向官方报 bug，然后尝试自行修复。

这次我们将以一个官方已经修复的 bug为 例，详细介绍一下对于第一种情况的处理过程。

近期，我们在研发Klustron的存储节点新特性的过程中，发现一个 MySQL 的 crash 问题。

Crash 的堆栈信息如下：

通过分析 Crash 的堆栈和 core 文件信息，我们确定这是一个加列后的表在做 import tablespace 操作过程中的 Crash。于是，根据这些信息就可以去官方 Bug 库中搜索相关的 Bug。

第一步：根据 Bug 信息搜索官方 Bug 库，寻找官方修复

进入官方 Bug 库 MySQL Bugs ， 选择 Advanced search 标签页，输入关键字 “crash instant”，状态选择 “Closed”（已修复的 Bug）

点击 “Search” 就可以得到一个如下的 bug 列表：

仔细查看，发现 ID 为 107517 的 bug 跟我们碰到的问题相关，于是点进去查看详细信息如下：

Bug 页面中的 Crash 堆栈等各方 面信息都与我们碰到的 Crash 相同，于是，可以确定，这个 Bug 就是我们碰到的 Bug。

Bug 页面的最后部分说明这个 bug 已经在 8.0.31 版本修复，于是我们需要到 8.0.31 之后的版本去找到修复补丁。

另外，我们也可以在官方 8.0.31 的 release notes 里面找到这个 Bug 的相关信息：

这里面有个对应的两个 bug 号，其中 6 位（bug#107517）的是外部编号，也就是 bug 系统中我们可以看到的那个编号，而 8 位的内部号（bug#34307874）对应的页面只有 MySQL 内部的开发人员才能看到。

我们把这个 8 位的内部编号 bug#34307874 记下来，下一步会用到。

第二步：寻找官方修复补丁：

寻找官方修复补丁首先要在克隆好的官方代码库上通过 git log 拿到所有代码提交的 commit log，然后通过上一步拿到的内部 bug 号 bug#34307874 在其中查找到对应的 commit，拿到该 commit的id：8afe86a32dbafed86be55921ac75d8c8dfc89e4c。

然后，通过 git show8afe86a32dbafed86be55921ac75d8c8dfc89e4c > instant_import.bug 就可以拿到对应的 patch 了。

这里需要提醒的是，一个 Bug 可能有多个 commit，一定要把所有的 commit 对应的 patch 都拿到。

第三步：在自己本地代码库打上修复补丁

在获取到官方的所有修复代码后，我们需要在本地代码库中将所有补丁按照顺序一一打上。

所有 patch 打完并编译好 MySQL 后，需要进行简单的验证。

通常官方的修复都会有一个对应的 MTR test case，比如上面的例子里面就有一个新的 bug34307874.test 测试用例。在编译好的 mysql-test 目录下，执行 ：./mtr -mem bug34307874 就可以跑一遍这个测试用例，如果通过就说明 bug 已经修复。

接下来就可以将 MySQL 打包发布了。

以上主要介绍了一种如何处理官方已修复 Bug 的方法，这种方法适用于不想升级到官方已修复版本的场景，总体来说，并不复杂，希望能帮到大家。

后续的文章里，我们还会介绍如何自行修复遇到的官方 bug，以及将修复提交给官方的流程，敬请期待。

END