orczhou.com

MySQL

  • 如何处理遇到的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…)

  • MySQL Optimize Table

    ·

    orczhou

    很难说Optimize Table到底能不能提高系统运行效率，但是有一点是肯定的：它能够帮我们回收更多的空间、减少“碎片”（defragment）。

    1. 回收空间 Defragment

    在InnoDB的维护过程中，我们总会遇到磁盘耗尽、或者InnoDB Tablespaces用完的情况。这时候，在考虑扩容等方案之前，最好先使用Optimize Table试试。如果你的表大字段（Text Blob Varchar），并且更新、删除较频繁的话，Optimize之后可能会腾出大量的空间。 (more…)

  • InnoDB Plugin特性介绍-2：快速DDL

    ·

    orczhou

    InnoDB Plugin在快速DDL上做了一些改进，在做的实验中看到，创建secondary indexes时，大约快了20%。

    1. 原理

    在MySQL5.0里面，如果数据表的记录数很多，增加和删除索引是非常慢的。CREATE INDEX and DROP INDEX命令是通过先创建一个空的临时表，这个表就是你新增或删除索引后的结构，然后把原表中的全部记录都拷贝（插入）到新的临时表中，最后把原表删除，临时表重命名成原表。

    MySQL5.1的一些架构上的改变，可以简化上面的过程（不再需要逐行拷贝数据）。InnoDB Plugin利用这个改变，缩短了大多数情况下的索引变更时间。对InnoDB来说有两类索引：the clustered index and secondary indexes。因为InnoDB的主键是the clustered index，数据存放再此，所以，删除或者添加主键（the clustered index）逐行拷贝也是必须 (more…)