Facebook 分享迁移到 MySQL 8.0 的经验

Facebook 分享迁移到 MySQL 8.0 的经验

Facebook 在一篇博客中分享了该公司在某种程度上艰难的大规模跨越式迁移到 MySQL 8.0 版本的经验。此前，其一直使用的是 MySQL 5.6 版本。

MySQL 是由 *** 开发的开源数据库，为 Facebook 的一些最重要的工作负载提供支持。Facebook 方面称，MySQL 的每个新主要版本都需要其花费大量时间和精力来迁移工作负载。其中挑战包括有：

将其自定义功能移植到新版本确保复制在主要版本之间兼容最小化现有应用程序查询所需的更改修复阻止服务器支持其工作负载的性能回归

根据透露，Facebook 上次升级到 MySQL 5.6 花了一年多的时间;而此向 MySQL 8.0 的升级也花了好几年的时间。在 5.7 版本发布的时候，Facebook 仍在开发 5.6 版上的 LSM-Tree 存储引擎 MyRocks。鉴于在构建新存储引擎的同时升级到 5.7 会显着减缓 MyRocks 的进度，因此该团队选择继续使用 5.6 直到 MyRocks 完成。而 MySQL 8.0 则刚好是在 MyRocks 完成时发布的，所以 Facebook 选择升级以改进其存储引擎。

Facebook 指出，迁移到 8.0 明显比迁移到 5.6 要更困难。他们有 1700 个代码补丁要从其定制的 MySQL 5.6 分支迁移到 8.0。由于 Facebook 的 MySQL 新功能和不断添加到 5.6 代码库中的修复，使得这项工作变得非常复杂。

因为从 5.6 到 8.0 的升级完全跳过了 5.7，一些在 5.6 中活跃的 API 要么被弃用、要么被完全删除;这也就意味着任何使用旧 API 的应用程序都需要更新。且 Facebook 的一些功能也与 8.0 中的类似功能不向前兼容，需要弃用和向前迁移。

还有自定义代码文档参差不齐的问题。Facebook 称，它的大多数自定义代码都有良好的注释和文档。但其他的代码没有很好的文档，Facebook 需要挖掘旧的文件、帖子和代码注释来了解历史。

最终，Facebook 方面评估了 2300 多个补丁并将其中的 1500 个移植到了 MySQL 8.0。“我们已将许多 InnoDB 副本集转换为完全在 8.0 上运行。其余的大多数都处于迁移路径的不同阶段。现在我们的大部分自定义功能都已移植到 8.0，更新到 *** 的次要版本相对容易，我们计划跟上最新版本的步伐。”

“尽管我们在迁移的道路上遇到了种种障碍，但我们已经看到了运行8.0的好处。总的来说，新版本大大扩展了我们在 MySQL @ Facebook 上所能做的事情。”

更多详情可查看官方博客。

本文标题：Facebook 分享迁移到 MySQL 8.0 的经验

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。