orczhou.com

testing-04

MySQL

  • MySQL/InnoDB源代码：线程并发访问控制

    ·

    orczhou

    作为DBA关心的更多的可能是原理、机制，对于源码一般大家也不是特别关心，也不太用得上。而且对于对于源代码级别的细节也很难用文字表达自己的理解，最终理解必须还是需要自己去看看每一行代码到底是怎样的。也读过《Understanding.MySQL.Internals》的大部分章节，作者也是偏重于从代码的实现目的（原理、机制）来介绍的，国内的《MySQL核心内幕》（个人对于“核心内幕”这个词有莫名的反感）算是更多的从源码开始介绍MySQL了，可是这本书也许是授予篇幅的限制，介绍的东西也并不多。

    开始写这篇文章，不能期待自己能写多少，也不能期待自己能研究多少，不过至少走出了自己探索的第一步。文章的宗旨不在于能够多么细致的分析MySQL的源代码，而是希望能给自己，能给他人打开走向源代码的第一道门。

    我是BNU数学系毕业的，对C语言知道甚少，C语言的经历大概就是“计算方法”课程中实现的求解各种方程的撇脚程序了。所以虽然我会极力避免错误，但是相信还是会犯一堆错误，希望各位看官能够宽容点，有错误指出来，慢慢改正。

    0. 开始

    InnoDB的代码通过宏定义考虑很多平台的兼容问题，这里分析的主要是类Unix/Linux平台（POSIX标准）的代码段，所以下面的很多代码段也是删除相关兼容性代码的。本文InnoDB源码是Plugin1.0.6版本。 (more…)

  • 编译安装MySQL

    ·

    orczhou

    使用rpm包，或者apt-get、yum等方式安装MySQL已经很方便了，不过我还是更喜欢编译安装。编译安装的好处：平台无关、安装的MySQL目录独立（方便清楚），据说有更好的性能和平台耦合。缺点，编译安装较慢（不过现在8核CPU编译起来也很快了）。

    1. MySQL编译参数

    常用的参数有：

    CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors \
-fno-exceptions -fno-rtti" ./configure \
--prefix=/data/mysql --with-extra-charsets=latin1,gbk,utf8 \
--with-plugins=partition,heap,innobase,myisam,myisammrg,csv \
--enable-assembler
make
make install

    “If you are using a version of gcc recent enough to understand the -fno-exceptions option, it is very important that you use this option. Otherwise, you may compile a binary that crashes randomly. Also use -felide-constructors and -fno-rtti along with -fno-exceptions.” (more…)

  • 如何处理遇到的MySQL Bug

    ·

    orczhou

    当管理的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补丁。

  • InnoDB Trouble:frm file and the InnoDB data directory out of sync.

    ·

    orczhou

    起因

    昨天，在给一个数据表DDL操作时，InnoDB报了如下错误：

    100602 13:48:39 [ERROR] Index uk_usplugin_plugid of test/test_user_plugin_0002 has 2 columns unique inside InnoDB, but MySQL is asking statistics for 3 columns. Have you mixed up .frm files from different installations? See http://dev.mysql.com/doc/refman/5.1/en/innodb-troubleshooting.html

    MySQL版本：MySQL5.1.45+InnoDB Plugin1.0.6

    当时的DDL：

    alter table test_user_plugin_0002 drop index USER_ID,add unique index uk_pluser_userid(USER_ID,PLUGIN_ID);

    追踪

    在MySQL Bug System中看到，问题类似于Bug #44571中的Case2（Bug #47622）。问题的大概原因是，InnoDB的system table中的表信息和MySQL字典中的表信息不同步导致的。尝试了几次，无法重现错误。

    如何避开（workaround）

    可以通过下面的SQL来重建InnoDB的索引：

    alter table test_user_plugin_0002 engine=innodb

    在Bug #47622看到5.1.46中貌似已经解决了这个问题，还可以尝试升级到5.1.46。

    另外，应该还可以尝试在DDL时打开old_alter_table来避免：（未验证）

    SET [GLOBAL] old_alter_table=ON

  • InnoDB Plugin特性介绍：让Buffer Pool不被污染

    ·

    orczhou

    较之MyISAM的一个很大的优势是，InnoDB会缓存数据块。如果系统中的数据量并不大，或者或者活跃数据量并不大时，InnoDB会将这些数据块全部缓存到Buffer Pool（内存）中，这样可以最大限度的提高提供的响应速度，特别是读取。当用户请求需要查询数据块时，InnoDB会首先在Buffer Pool中查找数据，如果Buffer Pool中没有该数据块时，InnoDB会从磁盘上Load对应的数据块，并通过LRU算法替代当前Buffer Pool的缓存块。

    1. Buffer Pool中LRU缺点、细节

    这样LRU算法的一个缺点是，如果有某一个查询做了一次全表扫描（例如备份，临时DDL等），都可能会导致整个Buffer Pool中LRU链表中的数据块都被替换了，甚至很多热点数据也会被替换，而这些新进的数据块可能在这一次查询之后就再也不会被读到了。我们也称这种情况为“Buffer Pool被污染”了。

    在InnoDB则引入了一些新的机制来避免这种情况。算法仍然是LRU算法，但是加上了中点策略（类似于MyISAM的key buffer中的midpoint strategy）。同时引入了参数innodb_old_blocks_time来控制Buffer Pool不被污染。

    LRU链表中的数据分为两部分：Sublist of new和Sublist of old。后者包含访问最近没有访问的数据块（链表越后面的数据块，最近越没有被访问）。默认情况，前者占63%（5/8），后者37%（3/8）。

    BufferPoolLRU (more…)

  • InnoDB Corruption

    ·

    orczhou

    以前没有遇到InnoDB文件损坏的情况，特此记录。从日志来看，损坏的应该是一个索引页，导致对应的数据表无法访问，也无法获取对应数据表中的数据，尝试check optimize也无法修复。最后设置innodb_force_recovery=1后启动数据库后，能够导出全部数据。

    1. 故障

    最近，在从一个Xtrabackup的备份中恢复数据后，发现MySQL数据库能正常启动，但是发现use dbname一下MySQL就会崩溃，看日志： (more…)