Amazon Aurora MySQL 版本 2（兼容 MySQL 5.7）升级到版本 3（兼容 MySQL 8.0）检查清单，第 1 部分

Amazon Aurora MySQL 兼容版版本 2（兼容 MySQL 5.7）计划于 2024 年 10 月 31 日终止标准支持。我们的公开文档中讨论了 Amazon Aurora MySQL 版本 2 的标准支持终止时间表。我们建议您在 2024 年 10 月 31 日之前，尽早将数据库升级到 Amazon Aurora MySQL 3 的默认次要版本或更高版本。Amazon Aurora MySQL 版本 3（兼容 MySQL 8.0）具备多种优势，例如社区增强功能、Amazon Aurora Serverless V2、Amazon Aurora 零 ETL、Amazon Aurora I/O 优化版、增强二进制日志（binlog）和 AWS Graviton3 支持。

在升级期间，升级操作要求应用程序停机一段时间。Amazon Aurora MySQL 将升级整个集群的引擎版本；因此，升级操作会在写入器和读取器数据库实例上一起执行。升级所需的时长取决于多个因素，例如架构的属性，包括表和索引的数量、数据库元数据的大小以及集群的繁忙程度。您可以通过数据库克隆来进行升级测试，从而确定升级所需的时间。请注意，创建测试环境会产生额外费用。

升级可以采用就地升级方法、快照和还原方法，或者使用 Amazon RDS 蓝/绿部署来执行，后者是尽可能缩短升级期间应用程序停机时间的首选方法。升级主要版本时，升级前后均需要全面细致的规划和测试。在这篇博文中，我们将讨论导致升级和升级预检查失败的最常见原因。这些问题需要在执行升级之前加以解决。

升级预检查

Amazon Aurora MySQL 执行的主要版本升级是一个多阶段过程，这个过程的第一步是升级预检查。MySQL 8.0 带来了许多增强功能，但需要注意的是，有一些地方与 MySQL 5.7 不兼容，这可能会在从 Amazon Aurora MySQL 版本 2 升级到版本 3 的过程中导致潜在问题。当您开始升级时，Amazon Aurora MySQL 会自动运行预检查过程来检测这些不兼容的情况。在就地升级中，预检查过程在关闭数据库实例进行升级之前运行，这意味着在运行预检查期间不会导致停机。如果预检查过程发现不兼容的情况，Aurora 会在数据库实例关闭之前自动取消升级。在快照还原和 Amazon RDS 蓝/绿部署方法中，如果升级到 Amazon Aurora MySQL 版本 3 的过程失败，则表明在创建然后升级写入器实例时检测到问题。Aurora 将保留原始的 5.7 兼容版的写入器实例。这样，您就可以检查 Amazon Aurora MySQL 在执行升级之前运行的预检查过程所生成的日志。Aurora 将有关各种不兼容情况的详细信息都记录在日志文件 upgrade-prechecks.log。您可以使用 CLI 命令 download-db-log-file-portion 下载此文件。

在升级生产数据库之前，最佳做法是为生产数据库创建克隆，然后对克隆的集群执行就地升级，以检查集群是否存在不兼容问题。当 upgrade-prechecks.log 中的 detectedProblems 字段包含级别值 Error 时，这意味着您必须纠正这些问题，然后才能成功升级。要汇总错误并显示关联的对象和说明字段，您可以对 upgrade-prechecks.log 字段的内容运行命令 grep -A 2 '"level": "Error"'。执行此操作后，将会为每个错误显示一行，后跟另外两行。这些行中包含对应的数据库对象名称，以及如何更正问题的指南。以下是一个示例：

grep -A 2 '"level": "Error"' upgrade-prechecks.log

"level": "Error",

"dbObject": "test.testtable1",

"description": "Table test.testtable1 contains one or more capital letters in name while lower_case_table_names = 1"

"level": "Error",

"dbObject": "test.testtable2",

"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"

upgrade-prechecks.log 文件的末尾汇总了在检查中遇到的各种次要或严重问题的次数。errorCount 不为零就表示升级会失败。warningCount 不会直接影响升级过程，但建议尽可能修复这些问题，以避免将来在升级后可能会出现问题。

"errorCount": 2,

"warningCount": 58,

"noticeCount": 0,

"Summary": "2 errors were found.Please correct these issues before upgrading to avoid compatibility issues."

在接下来的部分中，我们将介绍导致升级预检查过程失败的最常见原因。

在集群的用户架构中，具有不一致的数据字典或中间表

数据字典是元数据的集合，用于跟踪表和索引等对象。MySQL 8 和 Amazon Aurora MySQL 版本 3 支持原子数据定义语言（DDL，Data Definition Language）语句，但 MySQL 5.7 和 Amazon Aurora MySQL 版本 2 不支持这种语句。因此，在 MySQL 5.7 和 Amazon Aurora MySQL 版本 2 中，突然中断的 DDL 可能会导致表的数据字典不一致。此问题是由于 MySQL 的设计所导致的，不是 Amazon Aurora MySQL 或 Amazon Relational Database（Amazon RDS）for MySQL 造成的。对于存在不一致数据字典问题的表，upgrade-prechecks.log 中会出现以下错误：

{
"id": "schemaInconsistencyCheck",
"title": "Schema inconsistencies resulting from file removal or corruption",
"status": "OK",
"description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted.Please check server logs, examine datadir to detect the issue and fix it before upgrade",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.inconsistent_dd_table",
"description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
}

在升级期间看到此问题时，如果以下选项之一适合您，我们建议您先尝试一下这些选项：

执行逻辑转储，然后恢复到新集群，接下来将新集群升级到 Aurora MySQL v3。此策略假设您不再需要有问题的表，因为它们不会移至新集群。您可以使用 mysqldump 或 mydumper 和 myloader 来利用多个并行线程。
如果有 binlog 副本集群，请仔细检查，确保不存在同样的问题，然后在没有副本延迟时将副本集群提升为独立集群。
如果您知道导致问题的 DDL/DCL 的运行时间，请执行时间点恢复（PiTR，Point in Time Recovery），恢复到原始 DCL 或 DDL 开始之前的某个时间点。将增量数据迁移到还原的集群，以尽可能减少数据丢失。

如果这些选项都不适合您，请联系 AWS Support。请注意，修复数据字典不一致的情况只能是尽力而为，在某些情况下，字典会处于不可恢复的状态。

集群中的表包含孤立 FULLTEXT 索引

创建 FULLTEXT 索引后删除索引，可能会遗留一些元数据，这些元数据会导致升级预检查过程失败并回滚升级。孤立索引称为悬空 FULLTEXT 索引。upgrade-prechecks.log 文件中输出了包含悬空 FULLTEXT 索引的有问题表的信息：

{
"id": "getDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported.It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sandbox.dangling_fulltext_index_table",
"description": "Table sandbox.dangling_fulltext_index_table contains dangling FULLTEXT index.Kindly recreate the table before upgrade."
}

要修复悬空 FULLTEXT 问题，您需要在 Aurora MySQL v2 集群的表上运行 OPTIMIZE TABLE 命令。例如，OPTIMIZE TABLE sandbox.dangling_fulltext_index_table;

集群中的对象带有保留关键字

MySQL 8.0 引入了保留关键字，而以前这些关键字并未保留。升级预检查器会在数据库对象名称及其定义和正文中，评估保留关键字的使用情况。如果它检测到存储过程、函数、事件和触发器等数据库对象中使用了保留关键字，则升级将失败并在 upgrade-prechecks.log 文件中输出错误：

{
"id": "routinesSyntaxCheck",
"title": "MySQL 8.0 syntax check for routine-like objects",
"status": "OK",
"description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar.A common reason is that they reference names that conflict with new reserved keywords.You must update these routine definitions and `quote` any such references before upgrading.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.EXCEPT",
"description": "at line 12,8: unexpected token '.'"
}

要解决此问题，在升级之前，您必须更新这些对象定义并将任何此类引用用反引号引起来。或者，您可以将名称更改为其它名称，这可能需要更改应用程序。

集群的表在列定义中包含无效字符

当您尝试升级 Amazon Aurora MySQL 数据库集群时，由于表的列注释定义中包含无效字符，升级过程可能会失败。在错误日志中，您可能会看到以下错误：

2023-09-19T03:11:27.361837Z 2 [ERROR] [MY-013140] [Server] Comment for table 'test.problematic_tables' contains an invalid utf8mb3 character string: '\x8E\xE8\x94'.

我们建议检查引擎错误日志以找出所有有问题的表，然后对这些表运行命令 SHOW CREATE TABLE <table_name>，并使用 SHOW WARNINGS 来检查警告，以便了解详情。在重试升级之前，您必须更新列的注释定义。

有关可能导致升级失败的其他常见问题的更多信息，请参阅 Changes in MySQL 8.0

总结

在这篇博文中，我们讨论了升级预检查过程，以及导致升级和升级预检查失败的常见问题，并说明了如何解决这些问题。在第 2 部分中，我们将讨论从 Amazon Aurora MySQL 2 升级到 Amazon Aurora MySQL 3 时，升级时间过长或者升级不成功的常见原因。

关于作者

Huy Nguyen 是 AWS Support 的高级工程师。他的专业特长是 Amazon RDS 和 Amazon Aurora。他通过为客户提供指导和技术援助，帮助客户在 AWS 云中构建可扩展、高度可用和安全的解决方案。

Leevon Abuan 是 AWS Support 的数据库工程师。他专注于 Amazon RDS 和 Amazon Aurora 领域，长期帮助客户解决在云端运行数据库时的复杂技术问题。

亚马逊AWS官方博客