Facebook MySQL 8.0 迁移之路

MySQL，一款由 Oracle 公司开发的开源数据库，Facebook 一些最关键的工作负载均有赖于它来提供动力。为了支持不断发展的业务需求，我们积极地开发了一些 MySQL 的新特性。这些功能改变了 MySQL 许多不同的领域，包括客户端连接器、存储引擎、优化器以及同步复制（replication） 。每次升级到 MySQL 新的大版本，我们都需要花费大量的时间和精力来迁移我们的工作负载。这些挑战包括：

• 将我们定制的一些功能移植到新版本；
• 确保同步复制功能在大版本之间的兼容性；
• 尽量让现有应用程序的查询需要做的改动最小化；
• 修复一些妨碍服务器支持工作负载的性能问题。

我们上一次大版本升级，还是升级到 MySQL 5.6，那一次用了一年多的时间才搞定。5.7 刚发布的时候，我们还处在基于 5.6 版本开发我们的 LSM-Tree 存储引擎 MyRocks[1] 的中期阶段。由于升级到 5.7，然后同时又同步开发一个新的存储引擎的话将会显著放缓 MyRocks 的开发进度，我们选择留在 5.6 版本，直到 MyRocks 开发完成。MySQL 8.0 版本发布时，我们刚刚把 MyRocks 发布到用户数据库（UDB）服务这一层。

该版本有着众多引人注目的特性，比如基于写集合的并行复制功能，以及一个提供原子性的 DDL 支持的事务数据字典。对我们来说，迁移到 8.0 也会为我们带来之前错过的一些 5.7 的特性，包括文档存储。5.6 版本已经接近尾声，我们希望在 MySQL 社区保持活跃，尤其是在我们搞的 MyRocks 存储引擎这块。8.0 的一些改进，比如即时 DDL，可以加快 MyRocks 的数据库模式变更速度，但是，为了使用这些功能，我们需要 8.0 版本的代码。考虑到更新代码的好处，我们最终决定迁移到 8.0 版本。我们将会分享我们是怎么搞定 8.0 迁移项目的 —— 以及在此过程中我们发现的一些“惊喜”。在我们最初确定项目的边界时，很显然，迁移到 8.0 将会比迁移到 5.6 或者 MyRocks 更加困难：

• 彼时，在我们内部定制的 5.6 分支上有超过 1700 个代码补丁要移植到 8.0。在我们移植这些补丁的同时，新的 Facebook MySQL 特性和补丁被源源不断地添加到 5.6 的代码库，让这个过程变得更加漫长；
• 我们的生产环境里运行了大量的 MySQL 服务器，它们为众多形式各异的应用程序提供服务。我们也有不少用来管理 MySQL 实例的软件基础设施。这些应用程序执行的操作有：收集一些统计数据以及管理服务器备份等；
• 从 5.6 升级到 8.0 完全跳过了 5.7 版本。5.6 里活跃的一些 API 在 5.7 版本可能已经被弃用了，到 8.0 可能就已经移除了，这就要求我们将那些用到了已经移除的 API 的应用程序更新到新版本；
• Facebook 用到的许多功能尽管和 8.0 版本的类似，但是并不是向前兼容的，我们需要一个弃用和升级迁移的方案；
• 运行 8.0 版本需要用到一些 MyRocks 的增强特性，包括本机分区和崩溃恢复。

代码补丁