【51CTO独家特稿】我最近把MySQL从一个早期的版本（MySQL 5.0）升级到了Percona Server 5.1。这是一个经典的升级场景，在升级过程中，可能会发生一些意外。主服务器和几个从服务器都需要升级。MySQL是一个共享的数据库，在这5年多的时间里，人们使用这个共享的数据编写了很多的应用程序。它没有提供一个通用的测试套件（我们可以使用这个测试套件来验证MySQL代码）。就像你猜测的那样，在这种情况下，那些原作者们还在继续努力，并且，没有人可以确切地知道哪个应用程序应该使用这个数据库，哪个应用程序不应该使用这个数据库。在正规的公司中，数据库对生产起着决定性的作用，所以我们不应该草率地进行升级。
首先，我们必须对现有的“同步”设置做一个全面地检查
当我们检查“同步”的一致性的时候，我们要确保“同步”是同步开始的，这样可以避免误报。“mk-table-checksum”是一个专用的工具。事实证明，同步触发器确实存在一个问题。这个问题可以通过升级来修复，所以，我们只需要把它放到账户里就可以了。（关于“mk-table-checksum”，具体可以参考：http://www.maatkit.org/doc/mk-table-checksum.html
然后，我们把数据库迁移到MySQL 5.1。因为这个数据库的体积比较小，所以，我们使用“mysqldump”命令来载入数据是最安全的方法，想想我们提到的这4年版本更新的价值。我们也可以运行“mysql_fix_privilege_tables”，这样可以确保新的“privilege”会被添加，我经常看到这件事情被彻底遗忘掉了。
下一个步骤是配置MySQL 5.0 到 5.1的“同步”，看看它是否可以正常工作
事实证明它无法正常工作，这是过去的一个bug（关于这个bug的具体信息，可以参考：http://bugs.mysql.com/bug.php?id=24432），在很多其他的环境中，我也看到过这个Bug会引起一些和升级有关的问题。在MySQL 5.0中，“INSERT ON DUPLICATE KEY UPDATE”存在一个未公开的同步问题。有很多种方法可以解决这个问题，但是，首先，我们决定要看一看它的影响到底有多大。我们让从服务器通过“skip-slave-errors=1105”来同步，看看我们是否会遇到其他问题，与此同时，我们检查了上个月的二进制日志，想看一看这个功能的使用频率。令人愉快的是几乎没有几个“INSERT ON DUPLICATE KEY UPDATE”查询实例，在这些查询中，只有一个涉及到了带有“AUTO_INCREMENT”列的表（会被这个bug影响）。修改那个应用程序，让它在那个实例中不使用“INSERT ON DUPLICATE KEY UPDATE”，是很容易做到的。所以，我们修改了那个应用程序。
现在，“同步”可以正常工作了，但是数据匹配吗？
（如果存在载入不当的数据，使用mysqldump命令会覆盖掉那些载入不当的数据。）我们让5.0和5.1的从服务器停在了同一位置，然后使用“mk-table-checksum”来确保数据是同步的。“mk-table-checksum”可以使用“同步”来检查一致性，但是直接比较两个服务器会更快一些，正好我们有备用的容量，我们可以使用这些容量。首先，我们使用默认的“CHECKSUM TABLE”算法来进行检查。当运行“SELECT INTO OUTFILE”的时候，我们发现有很多表报告校验错误，然后我们diff那些报告文件，并没有发现有什么不同。事实证明，这几年，“CHECKSUM TABLE”发生了一些微妙的变化，在某些情况下，它可以报告不同的校验值。使用“BIT_XOR”算法重新进行检查，可以排除那些误报。对于剩下的另外一张表，我们可以使用“mk-table-sync –print”（关于mk-table-sync ，具体可以参考：http://www.maatkit.org/doc/mk-table-sync.html），作为一个MySQL的diff工具，它可以看出表之间有什么区别。事实证明，当数据载入到Percona Server 5.1中的时候，在MySQL 5.0中存储“-0″的float列会显示成“0″。对于应用程序来说，这并不是一个问题，实际上，完全可以忽略掉这个问题。
现在，我们可以确定，写数据流可以正确地同步到新版本中。是检查读数据流行为的时候了。我们把所有从服务器都停在了同一个位置上，然后使用“tcpdump” 和 “mk-query-digest”（关于“mk-query-digest”，具体可以参考：http://www.maatkit.org/doc/mk-query-digest.html）从主服务器和从服务器获取样例性的读数据流。如果想让每种查询类型只检查特定数目的样本，可以使用“–sample=50”选项（或类似的选项）——否则，会浪费很多时间。使用“mk-upgrade”（关于“mk-upgrade”，具体可以参考：http://www.maatkit.org/doc/mk-upgrade.html）执行那些查询可以得到一些不同的结果，事实证明，这些结果也是误报——这是由于“mk-upgrade”在默认情况下使用“TABLE CHECKSUM”来检查结果集。“–compare-results-method rows”可以帮助你移除它们，并且，我们可以只比较查询时间方面的区别。在大多数情况下，查询时间方面的区别并不是很明显，或许Percona Server 5.1可以做的更好一些，但是，在两个查询中，优化器会改变那个明显落后的查询，然后，它们会被标记为“被修复”。
现在，我们有足够的信心可以确定，从服务器完全可以处理这个流量，我们可以把它们放在生产环境中了。但是，在升级主服务器以前，我们必须要考虑一下回滚计划，因为如果在升级过程中遇到一些问题，我们需要把主服务器回滚到MySQL 5.0。为了完成这个任务，我们从Percona Server 5.1回到MySQL 5.0重新配置“同步”，然后再次执行上面提到的那些检查——很高兴“同步”可以正常发挥作用，不存在“偏差”。这可以让我们简单地挂载到MySQL 5.0上，所有从服务器都会脱离这个新的主服务器，并且，这种情况会持续一段时间，同时，回滚到过去的设置也很简单。对于涉及到新的操作系统和硬件（它们都可能造成回滚）的MySQL版本升级来说，这是最好的选择。
在我看来，在MySQL升级过程中，聘请一个外部的顾问十分有必要。即使在一个团队中有一个优秀的MySQL DBA（Data Base Administrator），一般来说，主版本的升级频率也不应该超过3到5年一次，在这样一个团队中，如果没有很多应用程序需要升级，也是很难记录下这些经验的。在升级的时候，你遇到的问题可能是截然不同的，这主要取决于升级的版本——从MySQL 4.1升级到MySQL 5.0和从MySQL 5.0升级到MySQL 5.1遇到的问题是不同的。
原文标题：The story of one MySQL Upgrade
【编辑推荐】
