Second Life 升级 MySQL 的案例参考

尽管前一段时间有媒体报道 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 说明。