图片来自 包图网
在升级到 5.7 的同时构建一个新的存储引擎，会大大减慢 MyRocks 的进度，因此我们选择继续使用 5.6，直到 MyRocks 完成，MySQL 5.6 的寿命也即将结束，决定升级到 MySQL 8.0 。
官博介绍说，此次过程比之前的升级更具挑战。MySQL 是 Oracle 公司旗下的一个开源数据库，它为 Facebook 的一些最重要的工作负载提供了动力。我们积极开发 MySQL 中的新特性，以支持不断演化的需求。
这些特性对MySQL的许多方面进行了修改，包括客户机连接器、存储引擎、优化器以及复制。
为了迁移工作负载，对于每个新的 MySQL 主版本，我们都需要投入大量的时间和精力。
其中的挑战包括：
将自定义功能移植到新版本。
确保主要版本之间的复制兼容。
最小化现有应用程序查询所需的更改。
对阻碍服务器支持我们工作负载的性能退化进行修复。
我们最近一次的主版本升级是到 MySQL 5.6，它花了一年多的时间才推出。当5.7 版发布时，我们还在 5.6 版上开发 LSM 树存储引擎和 MyRocks。
在升级到 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 中的类似功能并不向前兼容，需要一种弃用或迁移途径。
MyRocks 的增强功能需要在 8.0 中运行，包括本地化分区和崩溃恢复。
代码补丁
首先我们建立了 8.0 分支，用于在开发环境中进行构建和测试。然后，我们开始从 5.6 分支移植补丁的漫长过程。开始的时候有 1700 多个补丁，但我们能将其组织成几个主要类别。
我们的大多数自定义代码都有很好的注释和描述，因此可以很容易地确定应用程序是否仍然需要它，或者是否可以将它删除。
通过特殊关键字或唯一变量名所启用的功能，也使得确定关联变得很容易，因为我们可以搜索应用程序代码库来找到它们的用例。
有些补丁非常晦涩难懂，需要做调查工作 — 挖掘旧的设计文档、邮件或代码评审注释，以了解它们的历史。
我们将每个补丁分入四类之一：
Drop：不再使用，或在 8.0 中具有同等功能的特性，不需要移植。
Build/Client：支持我们构建环境的非服务器特性，修改过的 MySQL 工具，比如 mysqlbinlog，或者增加的功能，如异步客户端 API 等，需要移植。
非 MyRocks 服务器：mysqld 服务器中与 MyRocks 存储引擎无关的特性，需要移植。
MyRocks 服务器：支持 MyRocks 存储引擎的特性，需要移植。
我们使用电子表格跟踪每个补丁的状态和相关历史信息，并且在删除补丁时记录理由。
更新相同特性的多个补丁被组在一起进行移植。移植并提交到 8.0 分支的补丁，用 5.6 提交信息进行了注释。
由于我们需要筛选大量的补丁，将不可避免地出现移植状态上的差异，这些注释帮助我们解决了此类问题。
客户端和服务器类别中的每个补丁都自然而然地成为一个软件发布里程碑。随着所有与客户端相关的更改的移植，我们能够将客户端工具和连接器代码更新到 8.0。
一旦所有非 MyRocks 服务器特性都被移植，我们就可以为 InnoDB 服务器部署 8.0 mysqld 了。完成 MyRocks 服务器特性移植使我们能够更新 MyRocks 安装。
有些复杂特性需要对 8.0 进行重大更改，一些方面存在很大的兼容性问题。例如，上游 8.0 binlog 事件格式与我们一些对 5.6 的定制修改不兼容。
Facebook 5.6 特性使用的错误代码与上游 8.0 分配给新特性的错误代码冲突。我们最终需要修补 5.6 服务器，以使其与 8.0 向前兼容。
完成所有这些特性的移植花了几年时间。到最终结束时，我们已经评估了 2300 多个补丁，并将其中 1500 个移植到了 8.0 版本。
迁移途径
我们将多个 mysqld 实例组合到一个 MySQL 副本集中。副本集中的每个实例都包含相同的数据，但在地理上分布到不同的数据中心，以提供数据可用性和故障切换支持。
每个副本集都有一个主实例。其余的实例都是从实例。主实例处理所有写流量，并将数据异步复制到所有从实例。
由 5.6 主/ 5.6 从所组成的副本集开始，最终目标是包含 8.0 主/ 8.0 从的副本集。
我们遵循一个类似于 UDB MyRocks migration plan 的迁移规划：
对于每个副本集，通过一个使用 mysqldump 生成的逻辑备份，创建并添加到 8.0 的从实例。这些从实例不提供任何应用程序读取流量。
在 8.0 从实例上开启读取流量。
允许将 8.0 从实例升级为主实例。
禁用 5.6 实例的读取流量。
移除所有 5.6 实例。
每个副本集可以独立地通过上述步骤进行迁移，并可根据需要停留在一个步骤上。
我们将副本集分成更小的组，在组中进行每一次迁移。如果发现问题，我们可以回滚到上一步。在某些情况下，副本集能够在其它副本集开始之前到达最后一步。
为了自动化迁移大量副本集，我们需要构建新的软件架构。可以通过简单地更改配置文件中的一行，将副本集组合并在每个阶段中移动它们。任何遇到问题的副本集都能单独回滚。
基于行的复制
作为 8.0 迁移工作的一部分，我们决定将使用基于行的复制(row-based replication，RBR)作为标准。一些 8.0 特性需要 RBR，并且它简化了 MyRocks 的移植工作。
我们的大多数 MySQL 副本集已经在使用 RBR，而那些仍然运行基于语句的复制(statement-based replication，SBR)的副本集不容易迁移。
这些副本集通常有不含任何高基数键的表。完全转向 RBR 是一个目标，但添加主键所需的长尾工作的优先级往往低于其它项目。
因此，我们将 RBR 作为 8.0 的要求。在评估并向每个表添加主键之后，我们今年切换了最后一个 SBR 副本集。
使用 RBR 还为我们提供了一个解决应用程序问题的替代解决方案，我们在将一些副本集移动到 8.0 主实例时遇到了这个问题，将在后面讨论。
自动化验证
大多数 8.0 迁移过程都涉及使用我们的自动化架构和应用查询来测试和验证 mysqld 服务器。
我们用来管理服务器的自动化基础架构在随着 MySQL 服务器的增长而增长。为了确保所有 MySQL 自动化组件都与 8.0 版本兼容，我们投资构建了一个测试环境，该环境利用虚拟机上的测试副本集来验证行为。
我们为 canary 编写了在 5.6 版本和 8.0 版本上运行的每个自动化组件的集成测试，并验证了它们的正确性。在进行此演练时，我们发现了几个错误和行为差异。
当 MySQL 架构的每一部分都在我们的 8.0 服务器上进行验证时，我们发现并修复了(或解决了)一些有趣的问题：
解析错误日志、mysqldump 输出或服务器 show 命令的文本输出的软件很容易损坏。服务器输出的细微变化常常会暴露出工具解析逻辑中的错误。
8.0 的默认 utf8mb4 排序规则设置导致 5.6 和 8.0 实例之间的排序规则不匹配。
8.0 表可能会使用新的 utf8mb4_0900 排序规则，即使对于由 5.6 的show create table生成的create语句也是如此，因为使用utf8mb4_general_ci 的 5.6 模式没有显式指定排序规则。
这些表差异通常会导致复制和模式验证工具出现问题;某些复制失败的错误代码发生了变化，我们必须修复我们的自动化程序来正确处理它们。
8.0 版本的数据字典废弃了 table.frm 文件，但是我们的一些自动化系统使用它们来检测表模式的修改。
我们必须更新自动化系统，以支持 8.0 中引入的动态权限。
应用程序验证
我们希望迁移对应用程序尽可能透明，但是有些应用程序的查询会出现性能退化，或者在 8.0 上会失败。
对于 MyRocks 迁移，我们构建了一个 MySQL 影子测试框架，该框架捕获生产流量并将其重放到测试实例中。
对于每个应用程序工作负载，我们在 8.0 上创建了测试实例，并向它们回放影子流量的查询。
我们捕获并记录了从 8.0 服务器返回的错误，并发现了一些有趣的问题。不幸的是，并非所有这些问题都是在测试过程中发现的。
例如，事务死锁是应用程序在迁移过程中发现的。在研究不同的解决方案时，我们可以暂时将这些应用程序回滚到 5.6 版本。
8.0 引入了新的保留关键字，其中一些关键字，如 groups 和 rank，与应用程序查询中常用的表列名或别名相冲突。这些查询没有通过反引号转义名称，导致解析错误。
使用了自动转义查询中列名的软件库的应用程序没有遇到这些问题，但并非所有应用程序都使用这些软件库。
解决这个问题很简单，但是需要时间来跟踪生成这些查询的应用程序属主和代码库。
在 5.6 和 8.0 之间还发现了有些 REGEXP 不兼容。
一些包含在 InnoDB 上的 insert ... on duplicate key 查询的应用程序遇到了 repeatable-read 事务死锁。
5.6 有一个 bug，在 8.0 中得到了修复，但是修复增加了事务死锁的可能性。
在分析了查询之后，我们能够通过降低隔离级别来解决该问题。这个选项对我们来说是可用的，因为我们已经切换到基于行的复制。
我们自定义的 5.6 文档存储和 JSON 函数与 8.0 不兼容。使用文档存储的应用程序需要将文档类型转换为文本以进行迁移。
对于 JSON 函数，我们向 8.0 服务器中添加了兼容 5.6 的版本，以便应用程序以后可以迁移到 8.0 API。
我们对 8.0 服务器的查询和性能测试发现了一些需要立即解决的问题：
我们发现在 ACL 缓存部分出现了新的互斥争用热点。当大量连接同时打开时，它们都会阻塞 ACL 检查。
当存在大量 binlog 文件并且 binlog 的高速写入导致频繁轮换文件时，binlog 索引访问也发现了类似的争用。
几个涉及临时表的查询被中断。这些查询会返回意外错误，或者运行时间太长以致超时。
内存使用量与 5.6 相比有所增加，特别是对于 MyRocks 实例，因为必须加载 8.0 中的 InnoDB 。
默认的 performance_schema 设置启用了所有工具集并消耗了大量内存。我们限制了内存使用，只启用了少量的工具，并对代码进行了更改，以禁用无法手动关闭的表。
然而，并不是所有增加的内存都是分配给 performance_schema 的。我们需要检查和修改各种 InnoDB 内部数据结构，以进一步减少内存占用。这一努力使 8.0 的内存使用率降到了可以接受的水平。
接下来的工作
到目前为止，8.0 的移植已经花了几年时间。我们已将许多 InnoDB 副本集转换为完全在 8.0 上运行。剩下的大部分都处于迁移途径的不同阶段。
现在，我们的大多数定制功能都已移植到 8.0，更新到 Oracle 的次版本相对容易些，我们计划跟上最新版本的步伐。
跳过 5.7 这样的主版本会带来一些问题，我们的迁移需要解决这些问题。
首先，我们无法就地升级服务器，需要使用逻辑转储和还原来构建新服务器。
但是，对于非常大的 mysqld 实例，这可能需要在活跃生产服务器上运行很多天，而且这个脆弱的过程可能会在完成之前被中断。对于这些大型实例，我们必须修改备份和恢复系统来应对重建。
其次，检测 API 更改要困难得多，因为 5.7 可能会向我们的应用程序客户端发出不推荐警告，以提示修复潜在的问题。
而我们需要在迁移生产工作负载之前，运行额外的影子测试来查找失败。使用自动转义模式对象名称的 mysql 客户端软件，有助于减少兼容性问题的数量。
在一个副本集中支持两个主版本非常困难。一旦副本集将其主实例升级为 8.0，最好尽快禁用并移除 5.6 实例。
应用程序用户往往会发现只有 8.0 支持的新特性，比如 utf8mb4_0900 排序规则，使用这些排序规则可能中断 8.0 和 5.6 实例之间的复制流。
尽管我们在迁移过程中遇到了种种障碍，但我们已经看到了运行 8.0 带来的好处。
一些应用程序选择了提早迁移到 8.0，以利用诸如文档存储和改进的日期时间支持等功能。
我们一直在考虑如何在 MyRocks 上支持像即时 DDL 这样的存储引擎特性。总的来说，新版本大大扩展了 MySQL@Facebook 的功能。
作者：Herman Lee，Pradeep Nayak，译者：王雪迎
编辑：陶家龙
出处：转载自公众号CSDN(ID：CSDNnews)
链接：https://engineering.fb.com/2021/07/22/data-infrastructure/mysql/
