以前没有遇到InnoDB文件损坏的情况，特此记录。从日志来看，损坏的应该是一个索引页，导致对应的数据表无法访问，也无法获取对应数据表中的数据，尝试check optimize也无法修复。最后设置innodb_force_recovery=1后启动数据库后，能够导出全部数据。
1. 故障
最近，在从一个Xtrabackup的备份中恢复数据后，发现MySQL数据库能正常启动，但是发现use dbname一下MySQL就会崩溃，看日志： (more…)
-
很难说Optimize Table到底能不能提高系统运行效率，但是有一点是肯定的：它能够帮我们回收更多的空间、减少“碎片”（defragment）。
1. 回收空间 Defragment
在InnoDB的维护过程中，我们总会遇到磁盘耗尽、或者InnoDB Tablespaces用完的情况。这时候，在考虑扩容等方案之前，最好先使用Optimize Table试试。如果你的表大字段（Text Blob Varchar），并且更新、删除较频繁的话，Optimize之后可能会腾出大量的空间。 (more…)
-
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…)
-
编写一个shell脚本，做一些事；改进这个脚本，更好做这件事；再改进这个脚本，帮自己做些其他的事情；再改进这个脚本帮助其他人做一些事……
简单的脚本处理，一般使用变量$0 $1 $2 …就可以依次获得全部参数，还可以通过$#获得这个脚本一共有多少个参数。如果你需要处理的情况（或者分支）更多的时候，这个方法就不凑效了，这时候，就可以考虑使用getopts了（man getopts）。
(more…) -
因为周六、日不用上班，最近周五晚上总会去网吧玩游戏了，一般从晚上8点玩到凌晨4点。结束游戏从网吧出来时，外面的早餐店已经开始新的一天工作。周六晚上一般还会再去网吧，从晚上8点再到凌晨。周日，睡上整整一天。
因为周六、日不用上班，最近周五晚上总会去网吧玩游戏了，一般从晚上8点玩到凌晨4点。结束游戏从网吧出来时，外面的早餐店已经开始新的一天工作。周六晚上一般还会再去网吧，从晚上8点再到凌晨。周日，睡上整整一天。
前一段时间有好几个周末就是这么过的，虽然很放纵，不过还是庆幸能有个爱好让自己如此沉浸。除了游戏，还认识了一群朋友，也让自己在这个复杂的世界中，感觉到一份简单。不知道像这样无所顾忌享受游戏还能坚持多久，也不知道这些朋友们哪一天会慢慢走向其他的“正业”，也担心自己未来也将慢慢失去自我，堕入这个“沉沦”的世界。
今天，在这里写下自己对自己，也对未来的自己的要求：
(more…) -
这两天是O’Reilly MySQL Conference & Expo，期间有很多关于MySQL的相关话题的介绍，包括MySQL、PBXT、Drizzle、MariaDB、XtraDB等等，不过最抢风头的应该是InnoDB1.0.7GA（with MySQL-5.5）的新特性，回头想想，Oracle/InnoDB也酝酿了很久的吧。
无论如何，这些新特性中最吸引我的是InnoDB的Faster Recovery。
一般地，MySQL/InnoDB都是运行在普通的PC Server + Linux（Unix），虽然不期待小型机+AIX的高可用，但想尽一切办法缩短MySQL的不可用时间，仍然是DBA的目标。根据经验，主机OS崩溃、硬件故障，仍然是影响MySQL可用性的最主要因素，当这些故障（OS、硬件）恢复后，另一个非常耗时的恢复就是InnoDB自己的恢复时间。一般主机发生一次重启，正常大约<5分钟，而这时InnoDB恢复可能需要40分钟或者更久（这依赖于Buffer Pool、脏页面比例、TPS等因素）。 (more…)