升级到 MySQL 8-CSDN博客

本文链接：https://blog.csdn.net/a369966697/article/details/137984338

1、代码补丁

首先我们建立了 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 版本。另外，关注公众号Java技术栈，在后台回复：面试，可以获取我整理的 MySQL 系列面试题和答案，非常齐全。

2、迁移途径

我们将多个 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 实例。

每个副本集可以独立地通过上述步骤进行迁移，并可根据需要停留在一个步骤上。我们将副本集分成更小的组，在组中进行每一次迁移。如果发现问题，我们可以回滚到上一步。在某些情况下，副本集能够在其它副本集开始之前到达最后一步。

为了自动化迁移大量副本集，我们需要构建新的软件架构。可以通过简单地更改配置文件中的一行，将副本集组合并在每个阶段中移动它们。任何遇到问题的副本集都能单独回滚。

点击关注公众号，Java干货****及时送达

3、基于行的复制

作为 8.0 迁移工作的一部分，我们决定将使用基于行的复制（row-based replication，RBR）作为标准。一些 8.0 特性需要 RBR，并且它简化了 MyRocks 的移植工作。我们的大多数 MySQL 副本集已经在使用 RBR，而那些仍然运行基于语句的复制（statement-based replication，SBR）的副本集不容易迁移。这些副本集通常有不含任何高基数键的表。完全转向 RBR 是一个目标，但添加主键所需的长尾工作的优先级往往低于其它项目。

因此，我们将 RBR 作为 8.0 的要求。在评估并向每个表添加主键之后，我们今年切换了最后一个 SBR 副本集。使用 RBR 还为我们提供了一个解决应用程序问题的替代解决方案，我们在将一些副本集移动到 8.0 主实例时遇到了这个问题，将在后面讨论。MySQL数据库开发的 36 条军规

4、自动化验证

大多数 8.0 迁移过程都涉及使用我们的自动化架构和应用查询来测试和验证 mysqld 服务器。另外，MySQL 系列面试题和答案全部整理好了，微信搜索Java技术栈，在后台发送：面试，可以在线阅读。

我们用来管理服务器的自动化基础架构在随着 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 中引入的动态权限。

5、应用程序验证

我们希望迁移对应用程序尽可能透明，但是有些应用程序的查询会出现性能退化，或者在8.0 上会失败。

对于 MyRocks 迁移，我们构建了一个 MySQL 影子测试框架，该框架捕获生产流量并将其重放到测试实例中。对于每个应用程序工作负载，我们在 8.0 上创建了测试实例，并向它们回放影子流量的查询。我们捕获并记录了从 8.0 服务器返回的错误，并发现了一些有趣的问题。不幸的是，并非所有这些问题都是在测试过程中发现的。例如，事务死锁是应用程序在迁移过程中发现的。在研究不同的解决方案时，我们可以暂时将这些应用程序回滚到 5.6 版本。

我们对 8.0 服务器的查询和性能测试发现了一些需要立即解决的问题。

内存使用量与 5.6 相比有所增加，特别是对于 MyRocks 实例，因为必须加载 8.0 中的 InnoDB 。默认的 performance_schema 设置启用了所有工具集并消耗了大量内存。我们限制了内存使用，只启用了少量的工具，并对代码进行了更改，以禁用无法手动关闭的表。

然而，并不是所有增加的内存都是分配给 performance_schema 的。我们需要检查和修改各种 InnoDB 内部数据结构，以进一步减少内存占用。这一努力使 8.0 的内存使用率降到了可以接受的水平。

6、接下来的工作

到目前为止，8.0 的移植已经花了几年时间。我们已将许多 InnoDB 副本集转换为完全在 8.0 上运行。剩下的大部分都处于迁移途径的不同阶段。现在，我们的大多数定制功能都已移植到 8.0，更新到 Oracle 的次版本相对容易些，我们计划跟上最新版本的步伐。

跳过 5.7 这样的主版本会带来一些问题，我们的迁移需要解决这些问题。

首先，我们无法就地升级服务器，需要使用逻辑转储和还原来构建新服务器。但是，对于非常大的 mysqld 实例，这可能需要在活跃生产服务器上运行很多天，而且这个脆弱的过程可能会在完成之前被中断。对于这些大型实例，我们必须修改备份和恢复系统来应对重建。

其次，检测 API 更改要困难得多，因为 5.7 可能会向我们的应用程序客户端发出不推荐警告，以提示修复潜在的问题。而我们需要在迁移生产工作负载之前，运行额外的影子测试来查找失败。使用自动转义模式对象名称的 mysql 客户端软件，有助于减少兼容性问题的数量。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。