想要从 MariaDB 10.4 迁移到 MySQL 8.0 但面临障碍？MySQL 5.7 来救援！

原文：https://www.percona.com/blog/want-to-migrate-from-mariadb-10-4-to-mysql-8-0-but-facing-hurdles-mysql-5-7-to-the-rescue/

请注意，MariaDB 10.4 不是最新版本，自 10.4 以来已经发布了新版本。客户要求迁移到云上的 MySQL 8.0 以实现特定的 RDS 功能。

注意：在迁移到 MySQL 8.0.x 之前，请务必验证您没有使用任何特定的 MariaDB 功能。

最近，我们有一个客户想要从 MariaDB 10.4 迁移到 MySQL 8.0，这种转变带来了一些挑战。版本之间的不兼容性和不支持的复制使得直接升级变得不可能。本博客将探讨升级过程中遇到的障碍以及挽救局面的创新解决方案。

不兼容的障碍
MariaDB 10.4 使用 Aria 引擎作为系统表。由于 Aria 是仅限 MariaDB 的引擎，因此对于 10.4 及之后的版本，直接进行 MariaDB 10.4 > MySQL 8“就地”升级是不可能的。我没有列出所有不兼容性/差异，但您可以在这里找到它们。出于好奇，我在测试虚拟机上尝试了就地升级，并遇到了一些重做日志格式错误/数据字典错误。

2023-05-12T08:10:38.946611Z 1 [ERROR] [MY-013894] [InnoDB] Found redo log file ./ib_logfile0 which has format (v104) and is stored outside #innodb_redo.
2023-05-12T08:10:38.946683Z 1 [ERROR] [MY-012930] [InnoDB] Plugin initialization aborted with error Generic error.
2023-05-12T08:10:39.374389Z 1 [ERROR] [MY-011013] [Server] Failed to initialize DD Storage Engine.

导入表空间 — 有风险且会导致停机
由于客户端数据集超过 1TB，我们在选择逻辑备份/恢复方法（安全/首选选项）之前尝试了其他更快的选项。我们尝试了架构转储和导入表空间（有关更多详细信息，请参阅导入 InnoDB 表），这在测试虚拟机上运行良好，但此选项涉及读锁定/停机时间，这对于生产设置来说不是首选，并且也被认为是有风险的选项。

逻辑备份/恢复方法 - 但如何保持数据同步？
最后，经过协商一致，选择逻辑备份/恢复选项作为最安全的选项。但之后，我们还必须测试“不受支持”的复制设置，以确保数据可以从 MariaDB 10.4 同步到 MySQL 8.x，直到我们准备好迁移到 MySQL 8.x 服务器。除了一些预期的用户创建语句失败（有一个简单的解决方法）之外，此复制测试在我的测试虚拟机上运行正常，数据最少。

然而，在使用客户数据进行测试时，我们就没那么幸运了；错误日志显示复制设置期间出现意外事件序列，导致 MySQL 8 节点崩溃。

[Warning] [MY-010590] [Repl] An unexpected event sequence was detected by the IO thread while queuing the event received from master 'source-bin.000046' binary log file, at position 368.
[Warning] [MY-010444] [Repl] QUERY(BEGIN) is not expected in an event stream in the middle of a DDL.
[Warning] [MY-010590] [Repl] An unexpected event sequence was detected by the IO thread while queuing the event received from master 'source-bin.000046' binary log file, at position 394363.

mysqld got signal 11 ;

我们针对该错误进行了研究，但很明显二进制日志不兼容，并且复制设置不可靠。

探索下一个选项——MySQL 5.7中间副本
我们需要一个复制链接来建立最小的中断，让我们有时间以最短的停机时间进行切换。由于复制到 MySQL 8 不起作用，我们尝试从 MariaDB 10.4 复制到 MySQL 5.7 以测试 binlog 兼容性。因此，我们在逻辑备份恢复后配置了MySQL 5.7副本。

它成功了！MariaDB 10.4 > MySQL 5.7 的复制设置有效，并且副本同步，没有任何问题。我们对副本进行了几天的监控，以确保没有遇到错误。后来我们配置了另一个节点，其中 MySQL 8.0 从 MySQL 5.7 节点复制，形成链式复制拓扑，并且像往常一样迁移到 MySQL 8.x。简而言之，拓扑配置如下：

结论
在这种情况下，引入 MySQL 5.7 中间副本被证明是一个有用的解决方案，克服了 MariaDB 10.4 和 MySQL 8.0 之间的复制挑战。它还显示了在复杂的数据库升级中进行彻底测试的重要性。我希望它能鼓励其他在数据库迁移过程中面临类似障碍的人考虑替代策略并拥抱测试成功结果的力量。或者您可以使用Percona来帮助解决这个问题！