orczhou.com

orczhou

  • 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…)

  • How to kill an `uninterruptible sleep` process

    ·

    orczhou

    很早之前就遇到一次这个故障，当时是一台主机故障，这次是上百台主机故障。当时是使用mysqldump向NFS备份时，写数据时大概是NFS出现故障，使得mysqldump进程进入uninterruptible sleep（man ps）状态：

    $ps axu|grep mysqldump
    mysql 2718 0.0 0.0 51088 672 pts/0 S+ 13:30 0:00 grep mysqldump
    mysql 14916 1.4 0.0 0 0 ? D 02:03 10:03 [mysqldump]

    进入该状态的进程，会一直等待NFS，不接受任何信号，当然也就无法被杀死（kill/fuser -k）。因为进程一直在运行队列（running queue）中，所以还会导致主机的Load上升（虽然主机并不繁忙）。如果由于这个原因被卡住的进程很多的话，主机的Load可能会看起来非常高。 (more…)

  • 关于CAP

    ·

    orczhou

    后知后觉仍然比不知不觉好一点，虽然我们努力最求的是先知先觉。

    在阅读了Eric A. Brewer的keynote at the PODC和Gilbert and Lynch的Brewer’s Conjecture and the Feasibility of Consistent,Available,Partition-Tolerant Web Service后，对CAP有了些初步的认识，也尝试弄清楚一些基本的问题。

    1. 为什么我们需要知道CAP

    记得当初学习数学科学（例如微分方程）的时候，如果求解一个问题，首先我们需要证明这个解的存在性。（没学过微分方程也可以回忆一下哥尼斯堡七桥问题）

    现实生活中，我们往往面临的是非常具体（甚至琐碎）的问题，我们也在不断付出巨大的努力的尝试解决它们。如果问题棘手，发现一时无法走出的困境后，往往会寻求新的设计方案来解决问题。每一个方案（系统）设计之初，参与设计者往往对未来这个方案充满了憧憬，事实上，新方案也一般能解决现有系统的瓶颈。但是新方案运行一段时间后，我们又会重新发现，我们绕过了一些问题，面对的是一些新的困境。

    为了避免这种情况，在设计新方案的时候，我们需要尝试弄清楚我们现在系统解决了哪些问题，没有解决哪些问题，无法解决哪些问题；设计新系统，我们能够解决哪些，无法解决哪些。

    CAP理论（也许不能说是严格理论，因为我们往往在C、A、P之前寻求平衡）便是基于这样的思考，产生的理论。 (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…)