Aurora MySQL 的主要版本升级预检查 - Amazon Aurora
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

Aurora MySQL 的主要版本升级预检查

将 MySQL 从一个主要版本升级到另一个主要版本,例如从 MySQL 5.7 升级到 MySQL 8.0,需要进行一些重大的架构更改,这要求进行仔细的规划和准备。与次要版本升级(重点主要是更新数据库引擎软件,在某些情况下还包括系统表)不同,主要 MySQL 升级通常会对数据库存储和管理其元数据的方式进行根本性的更改。

为协助您确定此类不兼容性,当从 Aurora MySQL 版本 2 升级到版本 3 时,Aurora 会自动运行升级兼容性检查(预检查),来检查数据库集群中的对象并确定可能阻碍升级继续进行的已知不兼容性。有关 Aurora MySQL 预检查的详细信息,请参阅 Aurora MySQL 的预检查描述参考。除了社区 MySQL upgrade checker utility 运行的预检查之外,还会运行 Aurora 预检查。

这些预检查是必需的。您不能选择跳过它们。预检查提供以下好处:

  • 它们可以减少遇到升级失败的可能性,而升级失败可能导致停机时间延长。

  • 如果存在不一致性,Amazon Aurora 将阻止继续升级,并提供日志以供您参阅。然后,您可以使用日志,通过解决不一致性来准备数据库以升级到版本 3。有关解决不兼容性的详细信息,请参阅 MySQL 文档中的 Preparing your installation for upgrade 和 MySQL Server 博客上的 Upgrading to MySQL 8.0? Here is what you need to know...

    有关升级到 MySQL 8.0 的更多信息,请参阅 MySQL 文档中的升级 MySQL

预检查在数据库集群变为脱机状态来进行主版本升级之前运行。如果预检查发现不兼容问题,Aurora 会在停止数据库实例之前自动取消升级。Aurora 还会针对不兼容问题生成事件。有关 Amazon Aurora 事件的更多信息,请参阅使用 Amazon RDS 事件通知

在完成预检查后,Aurora 在 upgrade-prechecks.log 文件中记录有关每项不兼容性的详细信息。在大部分情况下,日志条目包括用于纠正不兼容性的 MySQL 文档的链接。有关查看日志文件的更多信息,请参阅 查看和列出数据库日志文件

注意

由于预检查的性质,它们会分析数据库中的对象。此分析会导致资源消耗并增加完成升级的时间。有关预检查性能注意事项的更多信息,请参阅 Aurora MySQL 的预检查过程

Aurora MySQL 的预检查过程

如前所述,Aurora MySQL 升级过程涉及到在进行主要版本升级之前对数据库运行兼容性检查(预检查)。

对于就地升级,预检查会在写入器数据库实例处于联机状态时对该实例运行。如果预检查成功,升级将继续。如果发现错误,则会将错误记录在 upgrade-prechecks.log 文件中并取消升级。在再次尝试升级之前,请先解决在 upgrade-prechecks.log 文件中返回的所有错误。

对于快照还原升级,预检查将在还原过程中运行。如果成功,数据库将升级到新的 Aurora MySQL 版本。如果发现错误,则会将错误记录在 upgrade-prechecks.log 文件中并取消升级。在再次尝试升级之前,请先解决在 upgrade-prechecks.log 文件中返回的所有错误。

有关更多信息,请参阅查找 Aurora MySQL 主要版本升级失败的原因Aurora MySQL 的预检查描述参考

要监控预检查状态,可以查看数据库集群上的以下事件。

预检查状态 事件消息 操作

Started

正在进行升级准备:正在启动在线升级预检查。

失败

数据库集群处于无法升级的状态:升级预检查失败。有关更多详细信息,请参阅 upgrade-prechecks.log 文件。

有关排查升级失败原因的更多信息,请参阅

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html

查看 upgrade-prechecks.log 是否有错误。

纠正错误。

重试升级。

成功

正在进行升级准备:已完成在线升级预检查。

预检查成功,未返回任何错误。

查看 upgrade-prechecks.log 是否有警告和通知。

有关查看事件的更多信息,请参阅查看 Amazon RDS 事件

Aurora MySQL 的预检查日志格式

升级兼容性检查(预检查)完成后,可以查看 upgrade-prechecks.log 文件。日志文件包含每次预检查的结果、受影响对象和纠正信息。

错误会阻止升级。在重试升级之前,必须先解决这些问题。

警告和通知不那么重要,但我们仍建议您仔细查看它们,以确保应用程序工作负载不存在兼容性问题。尽快解决所有已发现的问题。

日志文件采用以下格式:

  • targetVersion:Aurora MySQL 升级的 MySQL 兼容版本。

  • auroraServerVersion:对其运行预检查的 Aurora MySQL 版本。

  • auroraTargetVersion:要升级到的 Aurora MySQL 版本。

  • checksPerformed:包含已执行的预检查列表。

  • id:正在运行的预检查的名称。

  • title:对正在运行的预检查的描述。

  • status:这并不指示预检查成功还是失败,但显示预检查查询的状态:

    • OK:预检查查询运行并成功完成。

    • ERROR:预检查查询运行失败。出现这种情况的原因可能是资源限制、实例意外重新启动或兼容性预检查查询被中断等问题。

      有关更多信息,请参阅此示例

  • description:不兼容性的一般描述,以及如何纠正该问题。

  • documentationLink:如果适用,此处会注明指向相关 Aurora MySQL 或 MySQL 文档的链接。有关更多信息,请参阅 Aurora MySQL 的预检查描述参考

  • detectedProblems:如果预检查返回错误、警告或通知,这会显示不兼容性的详细信息以及不兼容的对象(如果适用):

    • level:预检查检测到的不兼容性级别。有效级别如下所示:

      • Error:在您解决不兼容性之前,升级无法继续。

      • Warning:升级可以继续,但检测到已弃用的对象、语法或配置。请仔细查看警告,并尽快予以解决,以免在将来的版本中出现问题。

      • Notice:升级可以继续,但检测到已弃用的对象、语法或配置。请仔细查看通知,并尽快予以解决,以免在将来的版本中出现问题。

    • dbObject:在其中检测出不兼容性的数据库对象的名称。

    • description:有关不兼容性的详细描述,以及如何纠正该问题。

  • errorCount:检测到的不兼容性错误的数量。这些错误会阻止升级。

  • warningCount:检测到的不兼容性警告的数量。这些警告不会阻止升级,但应尽快予以解决,以免在将来的版本中出现问题。

  • noticeCount:检测到的不兼容通知的数量。这些通知不会阻止升级,但应尽快予以解决,以免在将来的版本中出现问题。

  • Summary:预检查兼容性错误、警告和通知计数的摘要。

Aurora MySQL 的预检查日志输出示例

下面的示例显示了您可能看到的预检查日志输出。有关运行的预检查的详细信息,请参阅 Aurora MySQL 的预检查描述参考

预检查状态为 OK,未检测到不兼容性

预检查查询成功完成。未检测到任何不兼容性。

{ "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext", "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns", "status": "OK", "detectedProblems": [] },
预检查状态为 OK,检测到错误

预检查查询成功完成。检测到一个错误。

{ "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns", "title": "Check for geometry columns on prefix indexes", "status": "OK", "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.", "detectedProblems": [ { "level": "Error", "dbObject": "test25.sbtest1", "description": "Table `test25`.`sbtest1` has an index `idx_t1` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `idx_t1` ON `test25`.`sbtest1`;" }, }
预检查状态为 OK,检测到警告

当预检查成功或失败时,可能会返回警告。

此处预检查查询成功完成。检测到两个警告。

{ "id": "zeroDatesCheck", "title": "Zero Date, Datetime, and Timestamp values", "status": "OK", "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.", "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/", "detectedProblems": [ { "level": "Warning", "dbObject": "global.sql_mode", "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" }, { "level": "Warning", "dbObject": "session.sql_mode", "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" } ] }
预检查状态为 ERROR,未报告任何不兼容性

预检查查询失败,出现一个错误,因此无法验证不兼容性。

{ "id": "auroraUpgradeCheckForDatafilePathInconsistency", "title": "Check for inconsistency related to ibd file path.", "status": "ERROR", "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class." }

这一失败的原因可能是实例意外重新启动,或数据库上正在运行的兼容性预检查查询被中断。例如,在较小的数据库实例类上,当实例上的可用内存不足时,可能会遇到这种情况。

在运行预检查时,可以使用 FreeableMemory Amazon CloudWatch 指标来验证实例上的可用内存。如果实例内存不足,建议在更大的数据库实例类上重试升级。在某些情况下,可以使用蓝绿部署。这支持在独立于生产工作负载的“绿色”数据库集群上运行预检查和升级,但这也会消耗系统资源。

有关更多信息,请参阅排查 Aurora MySQL 数据库的内存使用问题

预检查摘要,检测到一个错误和三个警告

兼容性预检查还包含有关源 Aurora MySQL 版本和目标 Aurora MySQL 版本的信息,以及位于预检查输出末尾的错误、警告和通知计数摘要。

例如,以下输出显示有人尝试从 Aurora MySQL 2.11.6 升级到 Aurora MySQL 3.07.1。此升级返回了一个错误、三个警告,但没有返回任何通知。由于返回错误时无法继续升级,因此必须解决 routineSyntaxCheck 兼容性问题并重试升级。

{ "serverAddress": "/tmp%2Fmysql.sock", "serverVersion": "5.7.12 - MySQL Community Server (GPL)", "targetVersion": "8.0.36", "auroraServerVersion": "2.11.6", "auroraTargetVersion": "3.07.1", "outfilePath": "/rdsdbdata/tmp/PreChecker.log", "checksPerformed": [{ ... output for each individual precheck ... . . { "id": "oldTemporalCheck", "title": "Usage of old temporal type", "status": "OK", "detectedProblems": [] }, { "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.select_res_word", "description": "at line 2,18: unexpected token 'except'" }] }, . . . { "id": "zeroDatesCheck", "title": "Zero Date, Datetime, and Timestamp values", "status": "OK", "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.", "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/", "detectedProblems": [{ "level": "Warning", "dbObject": "global.sql_mode", "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" }, { "level": "Warning", "dbObject": "session.sql_mode", "description": " of 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates" } ] }, . . . }], "errorCount": 1, "warningCount": 3, "noticeCount": 0, "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues." }

预检查 Aurora MySQL 的性能

兼容性预检查在数据库实例进入脱机状态来进行升级之前运行,因此在正常情况下,它们不会在运行时导致数据库实例停机。但是,它们可能会影响写入器数据库实例上运行的应用程序工作负载。预检查通过 information_schema 表访问数据字典,如果数据库对象很多,这可能会很慢。请考虑以下因素:

  • 预检查持续时间因数据库对象(例如表、列、例程和约束)的数量而异。包含大量对象的数据库集群可能需要更长的时间来运行预检查。

    例如,removedFunctionsCheck 可能需要更长的时间,并且会根据 stored objects 的数量使用更多的资源。

  • 对于就地升级,使用更大的数据库实例类(例如 db.r5.24xlarge 或 db.r6g.16xlarge),有助于通过使用更多 CPU 来更快地完成升级。可以在升级后缩小规模。

  • 跨多个数据库对 information_schema 进行的查询可能会很慢,尤其是对于许多对象和较小的数据库实例。在这类情况下,可以考虑使用克隆、快照还原或蓝绿部署来进行升级。

  • 预检查资源使用量(CPU、内存)会随着对象增加而增加,从而导致较小数据库实例上的运行时间更长。在这类情况下,可以考虑使用克隆、快照还原或蓝绿部署来进行升级测试。

    如果由于资源不足而导致预检查失败,则可以使用状态输出在预检查日志中检测到此问题:

    "status": "ERROR",

有关更多信息,请参阅Aurora MySQL 主要版本就地升级的工作原理为 Aurora MySQL 集群计划主要版本升级

社区 MySQL 升级预检查摘要

以下是 MySQL 5.7 和 8.0 之间不兼容性的一般列表:

  • 与 MySQL 5.7 兼容的数据库集群不得使用 MySQL 8.0 不支持的功能。

    有关更多信息,请参阅 MySQL 文档中的 MySQL 8.0 中删除的功能

  • 不得出现关键字或保留关键字违规情况。MySQL 8.0 中可能会保留一些以前未保留的关键字。

    有关更多信息,请参阅 MySQL 文档中的关键字和保留关键字

  • 要获得改进的 Unicode 支持,请考虑将使用 utf8mb3 字符集的对象转换为使用 utf8mb4 字符集。utf8mb3 字符集已弃用。此外,请考虑对字符集引用使用 utf8mb4 而不是 utf8,因为 utf8 当前是 utf8mb3 字符集的别名。

    有关更多信息,请参阅 MySQL 文档中的 utf8mb3 字符集(3 字节 UTF-8 Unicode 编码)

  • 不得有非默认行格式的 InnoDB 表。

  • 不得有 ZEROFILLdisplay 长度类型属性。

  • 不得有使用不支持本机分区的存储引擎的分区表。

  • MySQL 5.7 mysql 系统数据库中不得有与 MySQL 8.0 数据字典使用的表同名的表。

  • 不得有使用过时的数据类型或函数的表。

  • 不得有超过 64 个字符的外键约束名称。

  • sql_mode 系统变量设置中不得定义过时的 SQL 模式。

  • 不得有包含长度超过 255 个字符的单个 ENUMSET 列元素的表或存储过程。

  • 不得有驻留在共享 InnoDB 表空间中的表分区。

  • 表空间数据文件路径中不得有循环引用。

  • 不得有对 GROUP BY 子句使用 ASCDESC 限定符的查询和存储程序定义。

  • 不得有任何已移除的系统变量,并且系统变量必须使用适用于 MySQL 8.0 的新默认值。

  • 不得有零(0)日期、日期时间或时间戳值。

  • 不得有由于文件移除或损坏而导致的架构不一致。

  • 不得有包含 FTS 字符串的表名称。

  • 不得有属于不同引擎的 InnoDB 表。

  • 不得有对于 MySQL 5.7 无效的表或架构名称。

有关运行的预检查的详细信息,请参阅 Aurora MySQL 的预检查描述参考

有关升级到 MySQL 8.0 的更多信息,请参阅 MySQL 文档中的升级 MySQL。有关 MySQL 8.0 中变化的一般描述,请参阅 MySQL 文档中的 What is new in MySQL 8.0

Aurora MySQL 升级预检查摘要

Aurora MySQL 在从版本 2 升级到版本 3 时有自己的特定要求,包括以下各项:

  • 视图、例程、触发器和事件中不得有弃用的 SQL 语法,例如 SQL_CACHESQL_NO_CACHEQUERY_CACHE

  • 没有 FTS 索引的任何表上都不得有 FTS_DOC_ID 列。

  • InnoDB 数据字典和实际表定义之间不得有列定义不匹配。

  • lower_case_table_names 参数设置为 1 时,所有数据库和表名都必须为小写。

  • 事件和触发器不得有缺失的或空的定义程序或无效的创建上下文。

  • 数据库中的所有触发器名称都必须是唯一的。

  • Aurora MySQL 版本 3 不支持 DDL 恢复和快速 DDL。数据库中不得有与这些功能相关的构件。

  • 采用 REDUNDANTCOMPACT 行格式的表的索引不能大于 767 字节。

  • tiny 文本列上定义的索引的前缀长度不能超过 255 字节。对于 utf8mb4 字符集,这会将支持的前缀长度限制为 63 个字符。

    在 MySQL 5.7 中,使用 innodb_large_prefix 参数可支持更大的前缀长度。MySQL 8.0 中已弃用此参数。

  • mysql.host 表中不得有 InnoDB 元数据不一致。

  • 系统表中不得有列数据类型不匹配。

  • 不得有 XA 事务处于 prepared 状态。

  • 视图中的列名称不能超过 64 个字符。

  • 存储过程中的特殊字符不能不一致。

  • 表不能有数据文件路径不一致。

有关运行的预检查的详细信息,请参阅 Aurora MySQL 的预检查描述参考