现在，“同步”可以正常工作了，但是数据匹配吗?

　　(如果存在载入不当的数据，使用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遇到的问题是不同的。