现在，我们可以确定，写数据流可以正确地同步到新版本中。是检查读数据流行为的时候了。我们把所有从服务器都停在了同一个位置上，然后使用“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遇到的问题是不同的。 |
