您的位置:知识库 » 数据库

MySQL升级的那些事:外来的和尚会念经

来源: 51CTO  发布时间: 2010-11-28 22:21  阅读: 1038 次  推荐: 0   原文链接   [收藏]  
摘要:MySQL的版本演化还是比较快的,如何顺利的实现MySQL升级是一个挺有意思的过程,大家一起来共同研究。

  我最近把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

0
0

数据库热门文章

    数据库最新文章

      最新新闻

        热门新闻