如何处理遇到的MySQL Bug

2010-06-3  |  10:58分类:MySQL  |  标签:  |  

当管理的MySQL主机越来越多的时候,遇到Bug的可能性也就越来越大了。基本上,每隔一段时间,我们都会遇到一个Bug或者版本兼容问题。有些Bug已经修复(Bug #44571),有些Bug无法重现或者修复(Bug #39168)。即使Bug能够重现,我们也不能期待MySQL/Innobase能够多快的给出Patch,他们没有这个义务,我们也没有权利要求。

如何处理Bug?

尝试到找Bug重现的场景,确定他是一个Bug,而不是一个Mistake。一般遇到Bug,都能在MySQL Bug找到线索,如果能够确定是Bug,可以看看新的版本是不是已经修复,如果修复则可以考虑升级小版本号。对于更高的小版本号,我们有如下假设(或者认为)

  • 更高的小版本号解决了更多Bug;
  • 如果更高的小版本有新特性,那么意味着新特性可能带来更多的Bug;
  • 更高的小版本,仍然会有和老版本不兼容的地方;
  • 更高的小版本,有很cool的新特性;
  • 一般,小版本的升级不会影响应用。

所以,一般遇到Bug,新的小版本如果有修复,我们将优先考虑升级小版本号。

另外,找到Bug重现的场景,还可以考虑绕过Bug(workaround),让自己的应用或者DDL尽量避免Bug出现。有时候,新版本新特性会带来一些Bug,不得以我们还可以考虑降级版本,虽然这是不推荐的做法,因为这样的可能陷入死循环。

Bug?Debug!

纵然,Innobase/MySQL AB已经被Oracle收购,MySQL的源代码仍然受到GPL的保护,所以我们仍然能够获得源代码,这就意味着我们自己Debug也成为可能。很多做开源方案的团队、公司已经发布了很多Patch,一般是做性能提升或者功能增强,他们也在MySQL Bug上提交了很多Patch建议。

这里的另一个问题是,自己的团队是否可能去Debug、打补丁?一般地,如果能够找到源代码的Bug,将其提交到MySQL Bug上,等待更加理解整个架构的人去将代码Merge到源码树中,一般是比较靠谱的办法。这大概也是为什么,目前开源社区、团队产生的一般是性能提升或者功能增强补丁,而很少Debug补丁。

喜欢本文,那就收藏到:

发表您的评论