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

升级到 Aurora MySQL 版本 3

要了解将数据库从 Aurora MySQL 版本 2 升级到版本 3 的特定升级路径,可以使用以下方法之一:

提示

在某些情况下,您可以指定在升级时将数据库日志上载到 CloudWatch 的选项。若如此,请检查 CloudWatch 中的日志,以诊断升级操作期间出现的任何问题。此部分中的 CLI 示例演示如何使用 --enable-cloudwatch-logs-exports 选项执行此操作。

Aurora MySQL 版本 3 的升级计划

为了帮助您决定正确的升级时间和方法,您可以了解 Aurora MySQL 版本 3 与当前的 Aurora 和 MySQL 环境之间的区别:

  • 如果您要从 RDS for MySQL 8.0 或 MySQL 8.0 社区版进行转换,请参阅比较 Aurora MySQL 版本 3 和 MySQL 8.0 社群版

  • 如果您要从 Aurora MySQL 版本 2、RDS for MySQL 5.7 或社群 MySQL 5.7 升级,请参阅 比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3

  • 为任何自定义参数组创建新的 MySQL 8.0 兼容版本。将所有必要的自定义参数值应用于新参数组。咨询 Aurora MySQL 版本 3 的参数更改 以了解参数更改。

    注意

    对于大多数参数设置,您可以在两个点选择自定义参数组。也即,在您创建集群或稍后将参数组与集群关联时。

    但是,如果您将非原定设置设置用于 lower_case_table_names 参数,则必须提前使用此设置来设置自定义参数组。然后,在执行快照还原操作以创建集群时指定参数组。创建集群后,lower_case_table_names 参数的任何更改不会产生任何影响。

    我们建议您在从 Aurora MySQL 版本 2 升级到版本 3 时对 lower_case_table_names 使用相同的设置。

    使用基于 Aurora MySQL 的 Aurora 全局数据库时,如果开启了 lower_case_table_names 参数,则无法执行从 Aurora MySQL 版本 2 到版本 3 的就地升级。有关可以使用的方法的更多信息,请参阅主要版本升级。

  • 请查看您的 Aurora MySQL 版本 2 数据库架构和对象定义,以了解 MySQL 8.0 社区版中引入的新保留关键字的使用情况。请在升级之前执行此操作。有关更多信息,请参阅 MySQL 文档中的 MySQL 8.0 新关键字和保留关键字

您还可以在 MySQL 参考手册MySQL 8.0 中的变化中找到更多特定于 MySQL 的升级注意事项和提示。例如,您可以使用命令 mysqlcheck --check-upgrade 来分析现有的 Aurora MySQL 数据库并确定潜在的升级问题。

注意

在使用就地升级或快照还原技术升级到 Aurora MySQL 版本 3 时,我们建议使用更大的数据库实例类。例如,db.r5.24xlarge 和 db.r6g.16xlarge。这样,通过使用数据库实例上的绝大部分可用 CPU 容量,有助于更快地完成升级过程。在主要版本升级完成后,您可以更改为所需的数据库实例类。

完成升级后,您可以按照 Aurora MySQL 版本 3 的升级后清理 中的升级后步骤进行操作。最后,测试应用程序的功能和性能。

如果要从 MySQL 或社群 MySQL 进行 RDS 转换,请按照 将数据迁移到 Amazon Aurora MySQL 数据库集群 中所述的迁移过程进行操作。在某些情况下,作为迁移的一部分,您可以使用二进制日志复制将数据与 Aurora MySQL 版本 3 集群同步数据。如果是这样,源系统必须运行与 MySQL 5.7 兼容的版本,或者是 8.0.23 或更低的与 MySQL 8.0 兼容的版本。

使用快照还原方法从 Aurora MySQL 版本 2 升级到版本 3 的示例

以下 Amazon CLI 示例演示了将 Aurora MySQL 版本 2 集群升级到 Aurora MySQL 版本 3 的步骤。

第一步是确定要升级的集群版本。以下 Amazon CLI 命令显示如何操作。输出确认原始集群是一个与 MySQL 5.7 兼容的集群(运行 Aurora MySQL 版本 2.09.2 的集群)。

此集群至少包含一个数据库实例。为了使升级过程正常运行,此原始集群需要一个写入器实例。

$ aws rds describe-db-clusters --db-cluster-id cluster-57-upgrade-ok \ --query '*[].EngineVersion' --output text 5.7.mysql_aurora.2.09.2

以下命令显示如何检查特定版本中可用的升级路径。在此情况下,原始集群在运行版本 5.7.mysql_aurora.2.09.2。输出显示,此版本可以升级到 Aurora MySQL 版本 3。

如果原始集群使用的版本号太低而无法升级到 Aurora MySQL 版本 3,则升级需要额外的步骤。首先,还原快照以创建可升级到 Aurora MySQL 版本 3 的新集群。然后,拍摄该中间集群的快照。最后,还原中间集群的快照以创建新的 Aurora MySQL 版本 3 集群。

$ aws rds describe-db-engine-versions --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.09.2 \ --query 'DBEngineVersions[].ValidUpgradeTarget[].EngineVersion' [ "5.7.mysql_aurora.2.09.3", "5.7.mysql_aurora.2.10.0", "5.7.mysql_aurora.2.10.1", "5.7.mysql_aurora.2.10.2", "8.0.mysql_aurora.3.01.1", "8.0.mysql_aurora.3.02.0" ]

以下命令将创建集群的快照以升级到 Aurora MySQL 版本 3。原始集群将保持不变。稍后,您可以从快照中创建一个新的 Aurora MySQL 版本 3 集群。

aws rds create-db-cluster-snapshot --db-cluster-id cluster-57-upgrade-ok \ --db-cluster-snapshot-id cluster-57-upgrade-ok-snapshot { "DBClusterSnapshotIdentifier": "cluster-57-upgrade-ok-snapshot", "DBClusterIdentifier": "cluster-57-upgrade-ok", "SnapshotCreateTime": "2021-10-06T23:20:18.087000+00:00" }

以下命令将快照还原到运行 Aurora MySQL 版本 3 的新集群。

$ aws rds restore-db-cluster-from-snapshot \ --snapshot-id cluster-57-upgrade-ok-snapshot \ --db-cluster-id cluster-80-restored --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.02.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBClusterIdentifier": "cluster-80-restored", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "Status": "creating" }

还原快照可设置集群的存储空间并建立集群可以使用的数据库版本。集群的计算容量与存储是分开的。因此,在创建集群本身后,您可以为集群设置任何数据库实例。以下示例使用其中一个 db.r5 实例类创建一个写入器数据库实例。

提示

您可能拥有使用 db.r3、db.r4、db.t2 或 db.t3 之类较旧的实例类创建数据库实例的管理脚本。如果是这样,请修改脚本以使用 Aurora MySQL 版本 3 支持的其中一个实例类。有关可用于 Aurora MySQL 版本 3 的实例类的信息,请参阅 实例类支持

$ aws rds create-db-instance --db-instance-identifier instance-running-version-3 \ --db-cluster-identifier cluster-80-restored \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-running-version-3", "DBClusterIdentifier": "cluster-80-restored", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.02.0", "DBInstanceStatus": "creating" }

升级完成后,您可以使用 Amazon CLI 验证集群的特定于 Aurora 的版本号。

$ aws rds describe-db-clusters --db-cluster-id cluster-80-restored \ --query '*[].EngineVersion' --output text 8.0.mysql_aurora.3.02.0

您还可以通过调用 version 函数来验证数据库引擎特定于 MySQL 的版本。

mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.23 | +-----------+

排查 Aurora MySQL 版本 3 升级问题

如果升级到 Aurora MySQL 版本 3 未成功完成,您可以诊断问题的原因。然后,您可以对原始数据库架构或表数据进行任何必要的更改,然后再次运行升级过程。

如果在升级到 Aurora MySQL 版本 3 期间失败,则会在为还原的快照创建并升级写入器实例时检测到问题。Aurora 会遗留与 5.7 兼容的原始写入器实例。这样,您可以在执行升级之前从 Aurora 运行的初步检查中检查日志。以下示例从与 5.7 兼容的数据库开始,该数据库需要进行一些更改才能升级到 Aurora MySQL 版本 3。这些示例演示了首次尝试升级失败的方式以及如何检查日志文件。它们还展示了如何修复问题并运行成功的升级。

首先创建一个与 MySQL 5.7 兼容的新集群,名为 problematic-57-80-upgrade。顾名思义,此集群至少包含一个在升级到 MySQL 8.0 兼容版本期间会产生问题的架构对象。

$ aws rds create-db-cluster --engine aurora-mysql \ --engine-version 5.7.mysql_aurora.2.10.0 \ --db-cluster-identifier problematic-57-80-upgrade \ --master-username my_username \ --manage-master-user-password { "DBClusterIdentifier": "problematic-57-80-upgrade", "Status": "creating" } $ aws rds create-db-instance \ --db-instance-identifier instance-preupgrade \ --db-cluster-identifier problematic-57-80-upgrade \ --db-instance-class db.t2.small --engine aurora-mysql { "DBInstanceIdentifier": "instance-preupgrade", "DBClusterIdentifier": "problematic-57-80-upgrade", "DBInstanceClass": "db.t2.small", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available \ --db-instance-identifier instance-preupgrade

在打算升级的集群中引入一个有问题的表。创建 FULLTEXT 索引再删除索引,会遗留一些在升级期间导致问题的元数据。此示例指定了生成主用户密码并在 Secrets Manager 中对其进行管理的 --manage-master-user-password 选项。有关更多信息,请参阅“使用 Amazon Aurora 和 Amazon Secrets Manager 管理密码”。或者,您可以使用 --master-password 选项自行指定和管理密码。

$ mysql -u my_username -p \ -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com mysql> create database problematic_upgrade; Query OK, 1 row affected (0.02 sec) mysql> use problematic_upgrade; Database changed mysql> CREATE TABLE dangling_fulltext_index -> (id INT AUTO_INCREMENT PRIMARY KEY, txtcol TEXT NOT NULL) -> ENGINE=InnoDB; Query OK, 0 rows affected (0.05 sec) mysql> ALTER TABLE dangling_fulltext_index ADD FULLTEXT(txtcol); Query OK, 0 rows affected, 1 warning (0.14 sec) mysql> ALTER TABLE dangling_fulltext_index DROP INDEX txtcol; Query OK, 0 rows affected (0.06 sec)

此示例尝试执行升级过程。我们制作原始集群的快照,再等待快照创建完成。然后还原快照,指定与 MySQL 8.0 兼容的版本号。我们还为集群创建了写入器实例。此时会发生升级处理。然后等待写入器实例可用。无论成败与否,升级过程会在此时结束。

提示

如果使用 Amazon Web Services Management Console 还原快照,Aurora 会自动创建写入器实例,然后将其升级至请求的引擎版本。

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot { "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot", "DBClusterIdentifier": "problematic-57-80-upgrade", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" } $ aws rds wait db-cluster-snapshot-available \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot $ aws rds restore-db-cluster-from-snapshot \ --snapshot-id problematic-57-80-upgrade-snapshot \ --db-cluster-id cluster-80-attempt-1 --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.02.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBClusterIdentifier": "cluster-80-attempt-1", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "Status": "creating" } $ aws rds create-db-instance --db-instance-identifier instance-attempt-1 \ --db-cluster-identifier cluster-80-attempt-1 \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-attempt-1", "DBClusterIdentifier": "cluster-80-attempt-1", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.02.0", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available \ --db-instance-identifier instance-attempt-1

现在检查新创建的集群和关联的实例,验证升级是否成功。集群和实例仍在运行与 MySQL 5.7 兼容的版本。这意味着升级失败。如果升级失败,Aurora 仅遗留写入器实例,以便您检查任何日志文件。您无法使用新创建的集群重新启动升级过程。通过更改原始集群解决问题后,您必须再次运行升级步骤:为原始集群制作新快照,再将其还原到另一个与 MySQL 8.0 兼容的集群。

$ aws rds describe-db-clusters \ --db-cluster-identifier cluster-80-attempt-1 \ --query '*[].[Status]' --output text available $ aws rds describe-db-clusters \ --db-cluster-identifier cluster-80-attempt-1 \ --query '*[].[EngineVersion]' --output text 5.7.mysql_aurora.2.10.0 $ aws rds describe-db-instances \ --db-instance-identifier instance-attempt-1 \ --query '*[].{DBInstanceStatus:DBInstanceStatus}' --output text available $ aws rds describe-db-instances \ --db-instance-identifier instance-attempt-1 \ --query '*[].[EngineVersion]' --output text 5.7.mysql_aurora.2.10.0

为了获得升级过程中所发生情况的摘要,我们将得到新创建的写入器实例的事件列表。在此示例中,我们列出了过去 600 分钟内的事件,涵盖升级过程的整个时间间隔。列表中的事件不一定按时间顺序排列。突出显示的事件显示了确认集群无法升级的问题。

$ aws rds describe-events \ --source-identifier instance-attempt-1 --source-type db-instance \ --duration 600 { "Events": [ { "SourceIdentifier": "instance-attempt-1", "SourceType": "db-instance", "Message": "Binlog position from crash recovery is mysql-bin-changelog.000001 154", "EventCategories": [], "Date": "2021-12-03T20:26:17.862000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1" }, { "SourceIdentifier": "instance-attempt-1", "SourceType": "db-instance", "Message": "Database cluster is in a state that cannot be upgraded: PreUpgrade checks failed. More details can be found in the upgrade-prechecks.log file. Please refer to https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.MySQL80.html#AuroraMySQL.mysql80-upgrade-troubleshooting for more details on troubleshooting the cause of the upgrade failure", "EventCategories": [ "maintenance" ], "Date": "2021-12-03T20:26:50.436000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1" }, { "SourceIdentifier": "instance-attempt-1", "SourceType": "db-instance", "Message": "DB instance created", "EventCategories": [ "creation" ], "Date": "2021-12-03T20:26:58.830000+00:00", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:instance-attempt-1" }, ...

若要诊断问题的确切原因,请检查新创建的写入器实例的数据库日志。如果升级至与 8.0 兼容的版本失败,实例将包含一个文件名为 upgrade-prechecks.log 的日志文件。此示例说明了如何检测该日志是否存在,然后将其下载到本地文件以供检查。

$ aws rds describe-db-log-files --db-instance-identifier instance-attempt-1 \ --query '*[].[LogFileName]' --output text error/mysql-error-running.log error/mysql-error-running.log.2021-12-03.20 error/mysql-error-running.log.2021-12-03.21 error/mysql-error.log external/mysql-external.log upgrade-prechecks.log $ aws rds download-db-log-file-portion --db-instance-identifier instance-attempt-1 \ --log-file-name upgrade-prechecks.log --starting-token 0 \ --output text >upgrade_prechecks.log

upgrade-prechecks.log 文件为 JSON 格式。我们使用 --output text 选项下载该文件,避免在另一个 JSON 包装器中对 JSON 输出进行编码。对于 Aurora MySQL 版本 3 升级,此日志始终包含某些信息和警告消息。如果升级失败,日志仅包含错误消息。如果升级成功,则根本不会生成日志文件。以下节选内容显示了您可以查找的条目类型。

$ cat upgrade-prechecks.log { "serverAddress": "/tmp%2Fmysql.sock", "serverVersion": "5.7.12", "targetVersion": "8.0.23", "auroraServerVersion": "2.10.0", "auroraTargetVersion": "3.02.0", "outfilePath": "/rdsdbdata/tmp/PreChecker.log", "checksPerformed": [

如果 "detectedProblems" 为空,则说明升级并未遇到任何此类问题。您可以忽略这些条目。

{ "id": "oldTemporalCheck", "title": "Usage of old temporal type", "status": "OK", "detectedProblems": [] },

检查已删除变量或已更改默认值不会自动执行。Aurora 使用参数组机制,而不是物理配置文件。无论变量更改是否对数据库产生任何影响,您始终会收到一些带有 CONFIGURATION_ERROR 状态的消息。您可以查阅 MySQL 文档,了解有关这些更改的详细信息。

{ "id": "removedSysLogVars", "title": "Removed system variables for error logging to the system log configuration", "status": "CONFIGURATION_ERROR", "description": "To run this check requires full path to MySQL server configuration file to be specified at 'configPath' key of options dictionary", "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-logging" },

如果参数组中的 SQL_MODE 设置保留为默认值,则会出现有关被淘汰日期和时间数据类型的此警告。数据库可能包含也可能不包含具有受影响类型的列。

{ "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" } ] },

如果 detectedProblems 字段包含 level 值为 Error 的条目,表示只有解决这些问题,升级才能成功。

{ "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": "problematic_upgrade.dangling_fulltext_index", "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade." } ] },
提示

要汇总这些错误并显示关联的对象和描述字段,您可以对 upgrade-prechecks.log 文件的内容运行命令 grep -A 2 '"level": "Error"'。这样做会显示每个错误行及其后两行。其中包含相应数据库对象的名称以及有关如何解决问题的指导。

$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"' "level": "Error", "dbObject": "problematic_upgrade.dangling_fulltext_index", "description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."

对于 Aurora MySQL 版本 3 升级,defaultAuthenticationPlugin 检查始终显示此警告消息。这是因为 Aurora MySQL 版本 3 使用 mysql_native_password 插件而不是 caching_sha2_password。您无需针对此警告采取任何措施。

{ "id": "defaultAuthenticationPlugin", "title": "New default authentication plugin considerations", "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection ... "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication" }

upgrade-prechecks.log 文件末尾总结了每种类型的轻微或严重问题遇到的检查次数。非零 errorCount 表示升级失败。

], "errorCount": 1, "warningCount": 2, "noticeCount": 0, "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues." }

下一组示例演示了如何修复此特定问题并再次运行升级过程。此次升级成功。

首先,我们回到原始集群。然后,我们对这些表运行 OPTIMIZE TABLE tbl_name [, tbl_name] ...,这会导致以下错误:

Table `tbl_name` contains dangling FULLTEXT index. Kindly recreate the table before upgrade.

$ mysql -u my_username -p \ -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | mysql | | performance_schema | | problematic_upgrade | | sys | +---------------------+ 5 rows in set (0.00 sec) mysql> use problematic_upgrade; mysql> show tables; +-------------------------------+ | Tables_in_problematic_upgrade | +-------------------------------+ | dangling_fulltext_index | +-------------------------------+ 1 row in set (0.00 sec) mysql> OPTIMIZE TABLE dangling_fulltext_index; Query OK, 0 rows affected (0.05 sec)

有关更多信息,请参阅 MySQL 文档中的优化 InnoDB 全文索引OPTIMIZE TABLE 语句

作为替代解决方案,您可以创建一个新表,其结构和内容与具有错误元数据的表相同。实际上,您可能会在升级后将此表重命名为原始表名。

$ mysql -u my_username -p \ -h problematic-57-80-upgrade.cluster-example123.us-east-1.rds.amazonaws.com mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | mysql | | performance_schema | | problematic_upgrade | | sys | +---------------------+ 5 rows in set (0.00 sec) mysql> use problematic_upgrade; mysql> show tables; +-------------------------------+ | Tables_in_problematic_upgrade | +-------------------------------+ | dangling_fulltext_index | +-------------------------------+ 1 row in set (0.00 sec) mysql> desc dangling_fulltext_index; +--------+---------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +--------+---------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | txtcol | text | NO | | NULL | | +--------+---------+------+-----+---------+----------------+ 2 rows in set (0.00 sec) mysql> CREATE TABLE recreated_table LIKE dangling_fulltext_index; Query OK, 0 rows affected (0.03 sec) mysql> INSERT INTO recreated_table SELECT * FROM dangling_fulltext_index; Query OK, 0 rows affected (0.00 sec) mysql> drop table dangling_fulltext_index; Query OK, 0 rows affected (0.05 sec)

现在我们要经历与以前相同的过程。从原始集群创建快照,并将快照还原为与 MySQL 8.0 兼容的新集群。然后,我们创建一个写入器实例来完成升级过程。

$ aws rds create-db-cluster-snapshot --db-cluster-id problematic-57-80-upgrade \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2 { "DBClusterSnapshotIdentifier": "problematic-57-80-upgrade-snapshot-2", "DBClusterIdentifier": "problematic-57-80-upgrade", "Engine": "aurora-mysql", "EngineVersion": "5.7.mysql_aurora.2.10.0" } $ aws rds wait db-cluster-snapshot-available \ --db-cluster-snapshot-id problematic-57-80-upgrade-snapshot-2 $ aws rds restore-db-cluster-from-snapshot \ --snapshot-id problematic-57-80-upgrade-snapshot-2 \ --db-cluster-id cluster-80-attempt-2 --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.02.0 \ --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]' { "DBClusterIdentifier": "cluster-80-attempt-2", "Engine": "aurora-mysql", "EngineVersion": "8.0.mysql_aurora.3.02.0", "Status": "creating" } $ aws rds create-db-instance --db-instance-identifier instance-attempt-2 \ --db-cluster-identifier cluster-80-attempt-2 \ --db-instance-class db.r5.xlarge --engine aurora-mysql { "DBInstanceIdentifier": "instance-attempt-2", "DBClusterIdentifier": "cluster-80-attempt-2", "DBInstanceClass": "db.r5.xlarge", "EngineVersion": "8.0.mysql_aurora.3.02.0", "DBInstanceStatus": "creating" } $ aws rds wait db-instance-available \ --db-instance-identifier instance-attempt-2

这次,在升级完成后检查版本会确认版本号已更改,可反映 Aurora MySQL 版本 3。我们可以连接到数据库,可以确认 MySQL 引擎版本是与 8.0 兼容的版本。确认升级后的集群包含导致原始升级问题的表的固定版本。

$ aws rds describe-db-clusters \ --db-cluster-identifier cluster-80-attempt-2 \ --query '*[].[EngineVersion]' --output text 8.0.mysql_aurora.3.02.0 $ aws rds describe-db-instances \ --db-instance-identifier instance-attempt-2 \ --query '*[].[EngineVersion]' --output text 8.0.mysql_aurora.3.02.0 $ mysql -h cluster-80-attempt-2.cluster-example123.us-east-1.rds.amazonaws.com \ -u my_username -p mysql> select version(); +-----------+ | version() | +-----------+ | 8.0.23 | +-----------+ 1 row in set (0.00 sec) mysql> show databases; +---------------------+ | Database | +---------------------+ | information_schema | | mysql | | performance_schema | | problematic_upgrade | | sys | +---------------------+ 5 rows in set (0.00 sec) mysql> use problematic_upgrade; Database changed mysql> show tables; +-------------------------------+ | Tables_in_problematic_upgrade | +-------------------------------+ | recreated_table | +-------------------------------+ 1 row in set (0.00 sec)

Aurora MySQL 版本 3 的升级后清理

将任何 Aurora MySQL 版本 2 集群升级到 Aurora MySQL 版本 3 后,您可以执行以下其他清理操作:

  • 为任何自定义参数组创建与 MySQL 8.0 兼容的新版本。将所有必要的自定义参数值应用于新参数组。

  • 更新任何 CloudWatch 告警、设置脚本等,以便对名称受到包含性语言更改影响的任何指标使用新名称。有关此类指标的列表,请参阅 Aurora MySQL 版本 3 的包容性语言更改

  • 更新任何 Amazon CloudFormation 模板,以对名称受到包含性语言更改影响的任何配置参数使用新名称。有关此类参数的列表,请参阅 Aurora MySQL 版本 3 的包容性语言更改

空间索引

升级到 Aurora MySQL 版本 3 后,检查是否需要删除或重新创建与空间索引相关的对象和索引。在 MySQL 8.0 之前,Aurora 可以使用不包含空间资源标识符 (SRID) 的索引来优化空间查询。Aurora MySQL 版本 3 仅使用包含 SRID 的空间索引。在升级过程中,Aurora 会自动删除任何没有 SRID 的空间索引,并在数据库日志中打印警告消息。如果观察到此类警告消息,请在升级后使用 SRID 创建新的空间索引。有关 MySQL 8.0 中空间函数和数据类型更改的更多信息,请参阅 MySQL 参考手册中的 MySQL 8.0 中的变化