尽管前一段时间有媒体报道 Second Life 已经悄无声息的衰败，不过林登实验室的人也还是很忙，这不，刚把一堆 MySQL 服务器进行了升级，还进行了详尽的经验总结(Refer)。

原有的 MySQL 都是跑在 4.1 版本上（4.1.11），在 2007 年的时候计划升级到 5.0 版本，不过遭遇到了…嗯，失败。当时的 5.0 版本不够快。被迫回滚。之后中心 DB 一直运行 4.1 的版本，而 Slave 和其它 DB 都逐渐升级到了 5.0.51 的版本。

用 Python 和 RabbitMQ 写了一个支持 MySQL 协议的分布式压力测试框架，该工具用于捕捉产品环境中的流量并在测试环境下回放模拟，以便更加接近系统的真实运行情况。此外，使用了 Maatkit 工具包用于验证 SQL 语法以及数据。

4.1.11 与 5.0.51 的对比测试表明，5.0.51 比 4.1.11 要慢不少，经过与 Percona 的沟通后，决定升级到 5.0.84 。从我几天前这份 MySQL 版本的调查看， 5.0.84 也是目前用户采用比较多的版本。初步测试 5.0.84 的性能和 4.1.11 的性能相差无几，随后测试打了 Percona 与 Google 的补丁的版本，未作调整下收益不大。一些关键的参数需要作调整以便得到更好的 I/O 能力（要注意如果是 SSD 环境下 innodb_read_ahead 参数要做一点调整，16K 还是 32K ? 要测试才知道）。此外，将 Binlog 放到单独的块设备上，得到 10% 的提升。值得注意的是，默认的系统 I/O 调度器不是很适合，切换到 Deadline 后得到了 15% 的提升(参考 I/O 调度器与 DB的关系)。

经过一番折腾，峰值并发达到了14-16k QPS，只用了 80% I/O 能力，而 4.1.11 最高是 8200 QPS，5.0.51 最高 11,500 QPS，看到这里，猜测他们费这么大劲升级也就是要得到更好的并发能力?

然后是对代码的验证上，包括 SQL 在不同 DB 版本上的正确性以及 SQL 运行的效率，后者也就是执行计划稳定性。这两个测试主要是用 Maatkit 来做的。对于后者，我个人觉得他们的验证过程还有点黑盒子，或许应该关注到具体的 TOP SQL 才会更稳妥一些。此外，复制数据的一致性检查也有必要加以重视。

这台中心服务器数据量大约 250GB。当前所用的服务器是 8 核 Xeon E5450 CPU，64GB 内存，400GB 的直连磁盘(RAID 10)，接下来有计划表明要迁移到 16 核的机器上，并且将启用 SSD 。

总体来看，对 MySQL 升级的过程其实也不是那么简单的，也要有个方法论与好的方案才会保证最后升级的成功。

–EOF–
延伸参考：Percona 针对 MySQL 5.0.84 的 Patch 说明。