orczhou.com

orczhou

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

  • 使用getopts处理Shell脚本参数

    ·

    orczhou

    编写一个shell脚本，做一些事；改进这个脚本，更好做这件事；再改进这个脚本，帮自己做些其他的事情；再改进这个脚本帮助其他人做一些事……

    简单的脚本处理，一般使用变量$0 $1 $2 …就可以依次获得全部参数，还可以通过$#获得这个脚本一共有多少个参数。如果你需要处理的情况（或者分支）更多的时候，这个方法就不凑效了，这时候，就可以考虑使用getopts了（man getopts）。

    (more…)