上一篇:0.2秒居然复制了100G文件?
近日,Facebook 官博公布了他们的数据库版本从 MySQL 5.6 升级到了 MySQL 8.0,并且在官博记录了复盘详细的升级过程。
Facebook 称,他们最近的一次大版本升级到 MySQL 5.6 花了一年多时间才完成,还在 5.6 版上开发 LSM 树存储引擎,MyRocks。在升级到 5.7 的同时构建一个新的存储引擎,会大大减慢 MyRocks 的进度,因此我们选择继续使用 5.6,直到 MyRocks 完成,MySQL 5.6 的寿命也即将结束,决定升级到 MySQL 8.0 。
官博介绍说,此次过程比之前的升级更具挑战。
我们有许多 MySQL 服务器在生产环境中运行,为大量截然不同的应用程序提供服务。我们还有众多管理 MySQL 实例的软件架构。这些应用执行诸如收集统计数据或管理服务器备份之类的操作。
从 5.6 升级到 8.0 完全跳过了 5.7。在 5.6 中处于活动状态的 API 在 5.7中可能被弃用,而在 8.0 中可能会被移除,这要求我们必须更新所有使用了现已删除API的应用程序。
1、代码补丁
首先我们建立了 8.0 分支,用于在开发环境中进行构建和测试。然后,我们开始从 5.6 分支移植补丁的漫长过程。开始的时候有 1700 多个补丁,但我们能将其组织成几个主要类别。
我们的大多数自定义代码都有很好的注释和描述,因此可以很容易地确定应用程序是否仍然需要它,或者是否可以将它删除。通过特殊关键字或唯一变量名所启用的功能,也使得确定关联变得很容易,因为我们可以搜索应用程序代码库来找到它们的用例。有些补丁非常晦涩难懂,需要做调查工作 — 挖掘旧的设计文档、邮件或代码评审注释,以了解它们的历史。
我们将每个补丁分入四类之一:
我们使用电子表格跟踪每个补丁的状态和相关历史信息,并且在删除补丁时记录理由。更新相同特性的多个补丁被组在一起进行移植。移植并提交到 8.0 分支的补丁,用 5.6 提交信息进行了注释。由于我们需要筛选大量的补丁,将不可避免地出现移植状态上的差异,这些注释帮助我们解决了此类问题。
客户端和服务器类别中的每个补丁都自然而然地成为一个软件发布里程碑。随着所有与客户端相关的更改的移植,我们能够将客户端工具和连接器代码更新到8.0。一旦所有非 MyRocks 服务器特性都被移植,我们就可以为 InnoDB 服务器部署8.0 mysqld了。完成 MyRocks 服务器特性移植使我们能够更新 MyRocks 安装。
完成所有这些特性的移植花了几年时间。到最终结束时,我们已经评估了 2300 多个补丁,并将其中 1500 个移植到了 8.0 版本。另外,关注公众号互联网架构师,在后台回复:2T,可以获取我整理的 MySQL 系列面试题和答案,非常齐全。
2、迁移途径
我们将多个 mysqld 实例组合到一个 MySQL 副本集中。副本集中的每个实例都包含相同的数据,但在地理上分布到不同的数据中心,以提供数据可用性和故障切换支持。每个副本集都有一个主实例。其余的实例都是从实例。主实例处理所有写流量,并将数据异步复制到所有从实例。
由 5.6 主/5.6 从所组成的副本集开始,最终目标是包含 8.0 主/ 8.0 从的副本集。我们遵循一个类似于 UDB MyRocks migration plan 的迁移规划。
每个副本集可以独立地通过上述步骤进行迁移,并可根据需要停留在一个步骤上。我们将副本集分成更小的组,在组中进行每一次迁移。如果发现问题,我们可以回滚到上一步。在某些情况下,副本集能够在其它副本集开始之前到达最后一步。
为了自动化迁移大量副本集,我们需要构建新的软件架构。可以通过简单地更改配置文件中的一行,将副本集组合并在每个阶段中移动它们。任何遇到问题的副本集都能单独回滚。
3、基于行的复制
4、自动化验证
大多数 8.0 迁移过程都涉及使用我们的自动化架构和应用查询来测试和验证 mysqld 服务器。另外,MySQL 系列面试题和答案全部整理好了,微信搜索互联网架构师,在后台发送:2T,可以在线阅读。
我们用来管理服务器的自动化基础架构在随着 MySQL 服务器的增长而增长。为了确保所有 MySQL 自动化组件都与 8.0 版本兼容,我们投资构建了一个测试环境,该环境利用虚拟机上的测试副本集来验证行为。我们为 canary 编写了在 5.6 版本和 8.0 版本上运行的每个自动化组件的集成测试,并验证了它们的正确性。在进行此演练时,我们发现了几个错误和行为差异。
当 MySQL 架构的每一部分都在我们的 8.0 服务器上进行验证时,我们发现并修复了(或解决了)一些有趣的问题:
解析错误日志、mysqldump 输出或服务器 show 命令的文本输出的软件很容易损坏。服务器输出的细微变化常常会暴露出工具解析逻辑中的错误。
5、应用程序验证
我们希望迁移对应用程序尽可能透明,但是有些应用程序的查询会出现性能退化,或者在8.0 上会失败。
我们对 8.0 服务器的查询和性能测试发现了一些需要立即解决的问题。
6、接下来的工作
到目前为止,8.0 的移植已经花了几年时间。我们已将许多 InnoDB 副本集转换为完全在 8.0 上运行。剩下的大部分都处于迁移途径的不同阶段。现在,我们的大多数定制功能都已移植到 8.0,更新到 Oracle 的次版本相对容易些,我们计划跟上最新版本的步伐。
跳过 5.7 这样的主版本会带来一些问题,我们的迁移需要解决这些问题。
首先,我们无法就地升级服务器,需要使用逻辑转储和还原来构建新服务器。但是,对于非常大的 mysqld 实例,这可能需要在活跃生产服务器上运行很多天,而且这个脆弱的过程可能会在完成之前被中断。对于这些大型实例,我们必须修改备份和恢复系统来应对重建。
尽管我们在迁移过程中遇到了种种障碍,但我们已经看到了运行 8.0 带来的好处。一些应用程序选择了提早迁移到 8.0,以利用诸如文档存储和改进的日期时间支持等功能。我们一直在考虑如何在 MyRocks 上支持像即时DDL这样的存储引擎特性。总的来说,新版本大大扩展了 MySQL@Facebook 的功能。
感谢您的阅读,也欢迎您发表关于这篇文章的任何建议,关注我,技术不迷茫!小编到你上高速。
· END ·
最后,关注公众号互联网架构师,在后台回复:2T,可以获取我整理的 Java 系列面试题和答案,非常齐全。
正文结束
推荐阅读 ↓↓↓
1.不认命,从10年流水线工人,到谷歌上班的程序媛,一位湖南妹子的励志故事
5.37岁程序员被裁,120天没找到工作,无奈去小公司,结果懵了...
6.IntelliJ IDEA 2019.3 首个最新访问版本发布,新特性抢先看