与 MySQL 8.0 兼容的 Aurora MySQL 版本 3

您可以使用 Aurora MySQL 版本 3 来获得最新的 MySQL 兼容功能、性能增强功能和错误修复。接下来，您可以了解与 MySQL 8.0 兼容的 Aurora MySQL 版本 3。您可以了解如何将集群和应用程序升级到 Aurora MySQL 版本 3。

来自社群 MySQL 8.0 的功能

Aurora MySQL 版本 3 的初始版本与社群 MySQL 8.0.23 兼容。MySQL 8.0 引入了几项新功能，包括以下功能：

有关添加到 MySQL 8.0 社群版的功能的完整列表，请参阅博客文章 MySQL 8.0 中的完整新功能列表。

Aurora MySQL 版本 3 还包括对包容性语言的关键字的更改，从社群 MySQL 8.0.26 向后移植。有关更改的详细信息，请参阅 Aurora MySQL 版本 3 的包容性语言更改。

新的并行查询优化

Aurora 并行查询优化现在适用于更多的 SQL 操作：

有关这些增强功能的更多信息，请参阅 将并行查询集群升级到 Aurora MySQL 版本 3。有关 Aurora 并行查询的一般信息，请参阅 使用 Amazon Aurora MySQL 的并行查询。

Aurora MySQL 版本 3 的发布说明

有关所有 Aurora MySQL 版本 3 发布的发布说明，请参阅 Amazon Aurora MySQL 版本 3 的数据库引擎更新。

比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3

使用以下内容了解在将 Aurora MySQL 版本 2 集群升级到版本 3 时需要注意的更改。

Aurora MySQL 版本 2 和 3 之间的功能区别

在 Aurora MySQL for MySQL 5.7 中支持以下 Amazon Aurora MySQL 功能，但在 Aurora MySQL for MySQL 8.0 中不支持这些功能。

一些 Aurora MySQL 功能可用于 Amazon 区域和数据库引擎版本的特定组合。有关详细信息，请参阅Amazon Aurora 中受 Amazon 区域和 Aurora 数据库引擎支持的功能。

实例类支持

Aurora MySQL 版本 3 支持与 Aurora MySQL 版本 2 不同的一组实例类：

Aurora MySQL 版本 2 中的以下实例类不适用于 Aurora MySQL 版本 3：

检查管理脚本，查看有无任何创建 Aurora MySQL 数据库实例的 CLI 语句以及对 Aurora MySQL 版本 3 不可用的硬编码实例类名称。如有必要，请将实例类名称修改为 Aurora MySQL 版本 3 支持的名称。

有关 Aurora 实例类的完整详细信息，请参阅 Aurora 数据库实例类。

Aurora MySQL 版本 3 的参数更改

Aurora MySQL 版本 3 包括新的集群级和实例级配置参数。Aurora MySQL 版本 3 还删除了 Aurora MySQL 版本 2 中存在的一些参数。由于包容性语言的倡议，一些参数名称发生了变化。为了向后兼容，您仍可以使用旧名称或使用新名称检索参数值。但是，您必须使用新名称在自定义参数组中指定参数值。

在 Aurora MySQL 版本 3 中，lower_case_table_names 参数的值在创建集群时永久设置。如果对此选项使用非原定设置值，请在升级之前设置 Aurora MySQL 版本 3 自定义参数组。然后，在创建集群或快照还原操作期间指定参数组。

有关 Aurora MySQL 集群参数的完整列表，请参阅 集群级别的参数。该表涵盖了 Aurora MySQL 版本 1、2 和 3 的所有参数。该表包括一些说明，显示了 Aurora MySQL 版本 3 中哪些参数是新增的，哪些参数已从 Aurora MySQL 版本 3 中删除。

有关 Aurora MySQL 实例参数的完整列表，请参阅 实例级参数。该表涵盖了 Aurora MySQL 版本 1、2 和 3 的所有参数。该表包括一些说明，显示了 Aurora MySQL 版本 3 中哪些参数是新增的，哪些参数已从 Aurora MySQL 版本 3 中删除。它还包括显示哪些参数在早期版本中可修改，但不能在 Aurora MySQL 版本 3 中修改的说明。

有关已更改的参数名称的信息，请参阅 Aurora MySQL 版本 3 的包容性语言更改。

状态变量

有关不适用于 Aurora MySQL 的状态变量的信息，请参阅 不适用于 Aurora MySQL 的 MySQL 状态变量。

Aurora MySQL 版本 3 的包容性语言更改

Aurora MySQL 版本 3 与 MySQL 社群版的 8.0.23 版本兼容。Aurora MySQL 版本 3 还包括 MySQL 8.0.26 中与包容性语言的关键字和系统架构相关的更改。例如，现在首选 SHOW REPLICA STATUS 命令，而不是 SHOW SLAVE STATUS。

以下 Amazon CloudWatch 指标在 Aurora MySQL 版本 3 中有新名称。

在 Aurora MySQL 版本 3 中，只有新的指标名称可用。升级到 Aurora MySQL 版本 3 时，请务必更新依赖指标名称的任何告警或其他自动化。

以下状态变量在 Aurora MySQL 版本 3 中有新名称。

为了获得兼容性，您可以在初始的 Aurora MySQL 版本 3 中使用任何一个名称。未来版本将删除旧的状态变量名称。

以下配置参数在 Aurora MySQL 版本 3 中有新名称。

为了获得兼容性，您可以在初始的 Aurora MySQL 版本 3 中使用任何一个名称以检查 mysql 客户端中的参数值。您只能使用新名称修改自定义参数组中的值。未来版本将删除旧的参数名称。

以下存储过程在 Aurora MySQL 版本 3 中有新名称。

为了获得兼容性，您可以在初始的 Aurora MySQL 版本 3 中使用任何一个名称。未来版本将删除旧的过程名称。

AUTO_INCREMENT 值

在 Aurora MySQL 版本 3 中，Aurora 在重启每个数据库实例时保留每个表的 AUTO_INCREMENT 值。在 Aurora MySQL 版本 2 中，AUTO_INCREMENT 值在重启后不会保留。

当您通过从快照还原、执行时间点恢复和克隆集群来设置新集群时，不会保留 AUTO_INCREMENT 值。在这些情况下，AUTO_INCREMENT 值将根据创建快照时表中的最大列值初始化为该值。此行为与 RDS for MySQL 8.0 中的行为不同，其中 AUTO_INCREMENT 值在这些操作过程中将被保留。

读取器数据库实例上的临时表

您无法在 Aurora MySQL 读取器实例上使用 InnoDB 存储引擎创建临时表。在读取器实例上，InnoDB 存储引擎被配置为只读。确保读取器实例上的任何 CREATE TEMPORARY TABLE 语句均在 NO_ENGINE_SUBSTITUTION 模式关闭的情况下运行。

您收到的错误会有所不同，具体取决于您使用的是简单 CREATE TEMPORARY TABLE 语句还是变体 CREATE TEMPORARY TABLE AS SELECT。以下示例显示不同类型的错误。

此临时表行为仅适用于只读实例。第一个示例证实了这是会话连接到的实例类型。

mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  1 |
+--------------------+

对于简单的 CREATE TEMPORARY TABLE 语句，语句会在 NO_ENGINE_SUBSTITUTION SQL 模式开启时失败。当该 SQL 模式关闭时，它将成功。

mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';

mysql>  CREATE TEMPORARY TABLE tt2 (id int) ENGINE=InnoDB;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).
mysql> SET sql_mode = '';

mysql> CREATE TEMPORARY TABLE tt4 (id int) ENGINE=InnoDB;

mysql> SHOW CREATE TABLE tt4\G
*************************** 1. row ***************************
       Table: tt4
Create Table: CREATE TEMPORARY TABLE `tt4` (
  `id` int DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

对于 CREATE TEMPORARY TABLE AS SELECT 语句，无论 NO_ENGINE_SUBSTITUTION SQL 模式是否开启，语句都将失败。MySQL 社群版不支持存储引擎替换成 CREATE TABLE AS SELECT 或 CREATE TEMPORARY TABLE AS SELECT语句。对于这些语句，请从 SQL 代码中删除 ENGINE=InnoDB 子句。

mysql> set sql_mode = 'NO_ENGINE_SUBSTITUTION';

mysql> CREATE TEMPORARY TABLE tt1 ENGINE=InnoDB AS SELECT * FROM t1;
ERROR 3161 (HY000): Storage engine InnoDB is disabled (Table creation is disallowed).

mysql> SET sql_mode = '';

mysql> CREATE TEMPORARY TABLE tt3 ENGINE=InnoDB AS SELECT * FROM t1;
ERROR 1874 (HY000): InnoDB is in read only mode.

内部临时表的存储引擎

在 Aurora MySQL 版本 3 中，内部临时表的工作方式与早期的 Aurora MySQL 版本不同。现在，您不必在 InnoDB 与 MyISAM 存储引擎之间选择此类临时表，而是在 TempTable 与 InnoDB 存储引擎之间选择。

使用 TempTable 存储引擎，您可以另外选择如何处理某些数据。受影响的数据溢出了保存数据库实例的所有内部临时表的内存池。

这些选择可能会影响生成大量临时数据的查询的性能，例如，在大型表上执行诸如 GROUP BY 之类的聚合操作。

您首先在 TempTable 存储引擎与 MEMORY 存储引擎之间作出选择，以用于内部临时表。您可以通过设置参数 internal_tmp_mem_storage_engine 来执行此操作。此参数将取代 Aurora MySQL 版本 1 和 2 中使用的 internal_tmp_disk_storage_engine 参数。

TempTable 存储引擎为原定设置引擎。TempTable 对使用此引擎的所有临时表使用公用内存池，而不是每个表的最大内存限制。此内存池的大小由 temptable_max_ram 参数指定。对于具有 16GB 或以上内存的数据库实例，原定设置为 1GB，内存小于 16GB 的数据库实例原定设置为 16MB。内存池的大小会影响会话级别的内存消耗。

如果您使用 TempTable 存储引擎且临时数据超过了内存池的大小，Aurora MySQL 会使用辅助机制存储溢出数据。

您可以设置参数 temptable_use_mmap 和 temptable_max_mmap 来指定数据是溢出到内存映射的临时文件还是磁盘上的 InnoDB 内部临时表。这些溢出机制的不同数据格式和溢出标准可能会影响查询性能。他们通过影响写入磁盘的数据量和对磁盘存储吞吐量的需求来实现这一目标。

Aurora MySQL 存储溢出数据的方式不同，具体取决于您选择的数据溢出目标以及查询是在写入器还是读取器数据库实例上运行：

二进制日志复制

在 MySQL 8.0 社群版中，预设情况下，二进制日志复制处于开启状态。预设情况下，在 Aurora MySQL 版本 3 中，二进制日志复制处于关闭状态。

Aurora 支持从兼容 MySQL 5.7 的源到 Aurora MySQL 版本 3 的二进制日志复制。源系统可以是 Aurora MySQL 数据库集群、RDS for MySQL 数据库实例或本地 MySQL 实例。

与社群 MySQL 一样，Aurora MySQL 支持从运行特定版本的源复制到运行相同主要版本或更高版本的目标。例如，不支持从兼容 MySQL 5.6 的系统复制到 Aurora MySQL 版本 3。不支持将 Aurora MySQL 版本 3 复制到兼容 MySQL 5.7 的系统或兼容 MySQL 5.6 的系统。有关使用二进制日志复制的详细信息，请参阅 Aurora 与 MySQL 之间或 Aurora 与其他 Aurora 数据库集群之间的复制（二进制日志复制）。

Aurora MySQL 版本 3 包括对社群 MySQL 8.0 中二进制日志复制的改进，例如筛选的复制。有关社群 MySQL 8.0 改进的详细信息，请参阅 MySQL 参考手册中的服务器如何评估复制筛选规则。

多线程复制

对于 Aurora MySQL 版本 3，Aurora MySQL 支持多线程复制。有关使用信息，请参阅多线程二进制日志复制（Aurora MySQL 版本 3 及更高版本）。

二进制日志复制的事务压缩

有关二进制日志压缩的使用信息，请参阅 MySQL 参考手册中的二进制日志事务压缩。

以下限制适用于 Aurora MySQL 版本 3 中的二进制日志压缩：

比较 Aurora MySQL 版本 3 和社群 MySQL 8.0

您可以使用以下信息了解从不同的 MySQL 8.0 兼容系统转换为 Aurora MySQL 版本 3 时需要注意的更改。

一般来说，Aurora MySQL 版本 3 支持社群 MySQL 8.0.23 的功能集。MySQL 8.0 社群版的一些新功能不适用于 Aurora MySQL。其中一些功能与 Aurora 的某些方面不兼容，例如 Aurora 存储架构。不需要其他功能，因为 Amazon RDS 管理服务提供了同等的功能。社群 MySQL 8.0 中的以下功能不受支持或者在 Aurora MySQL 版本 3 中的工作方式有所不同。

有关所有 Aurora MySQL 版本 3 发布的发布说明，请参阅 Amazon Aurora MySQL 版本 3 的数据库引擎更新。

MySQL 8.0 功能在 Aurora MySQL 版本 3 中不可用

社群 MySQL 8.0 中的以下功能未提供或者在 Aurora MySQL 版本 3 中的工作方式有所不同。

基于角色的权限模型

使用 Aurora MySQL 版本 3，您无法直接修改 mysql 数据库中的表。特别是，您无法通过插入到 mysql.user 表来设置用户。相反，您可以使用 SQL 语句授予基于角色的权限。您仍然可以查询 mysql 表。如果您使用二进制日志复制，则直接对源集群上的 mysql 表进行的更改不会复制到目标集群中。

在某些情况下，您的应用程序可能会使用快捷方式通过插入到 mysql 表来创建用户或其他对象。如果是这样，请更改应用程序代码以使用相应的语句，例如 CREATE USER。

要在从外部 MySQL 数据库迁移期间导出数据库用户的元数据，您可以使用 mysqlpump 命令而非 mysqldump。使用下面的语法。

mysqlpump --exclude-databases=mysql --users

此语句将转储所有数据库，但 mysql 系统数据库中的表除外。它还包括用于重现迁移数据库中的所有 MySQL 用户的 CREATE USER 和 GRANT 语句。您也可以在源系统上使用 pt-show-grants tool 列出 CREATE USER 和 GRANT 语句来重现所有数据库用户。

为了简化对许多用户或应用程序的权限管理，您可以使用 CREATE ROLE 语句来创建具有一组权限的角色。然后，您可以使用 GRANT 和 SET ROLE 语句以及 current_role 函数将角色分配给用户或应用程序、切换当前角色以及检查哪些角色有效。有关 MySQL 8.0 中基于角色的权限系统的更多信息，请参阅 MySQL 参考手册中的使用角色。

Aurora MySQL 版本 3 包括一个具有以下所有权限的特殊角色。该角色命名为 rds_superuser_role。每个集群的主管理用户已经授予了此角色。rds_superuser_role 角色包括所有数据库对象的以下权限：

角色定义还包括 WITH GRANT OPTION，以便管理用户可以将该角色授予其他用户。特别是，管理员必须授予以 Aurora MySQL 集群作为目标执行二进制日志复制所需的任何权限。

SHOW GRANTS FOR rds_superuser_role@'%';
SHOW GRANTS FOR name_of_administrative_user_for_your_cluster@'%';

Aurora MySQL 版本 3 还包括可用于访问其他 Amazon 服务的角色。您可以将这些角色设置为 GRANT 语句的替代。例如，您可以指定 GRANT AWS_LAMBDA_ACCESS TO user 而不是 GRANT INVOKE LAMBDA ON *.* TO user。对于访问其他 Amazon 服务的程序，请参阅 将 Amazon Aurora MySQL 与其他Amazon服务集成。Aurora MySQL 版本 3 包括以下与访问其他 Amazon 服务相关的角色：

当您使用 Aurora MySQL 版本 3 中的角色授予访问权限时，还可以通过使用 SET ROLE role_name 或 SET ROLE ALL 语句来激活角色。下面的示例演示如何操作。将适当的角色名称替换为 AWS_SELECT_S3_ACCESS。

# Grant role to user
> GRANT AWS_SELECT_S3_ACCESS TO 'user'@'domain-or-ip-address'

# Check the current roles for your user. In this case, the AWS_SELECT_S3_ACCESS role has not been activated.
# Only the rds_superuser_role is currently in effect.
> SELECT CURRENT_ROLE();
+--------------------------+
| CURRENT_ROLE()           |
+--------------------------+
| `rds_superuser_role`@`%` |
+--------------------------+
1 row in set (0.00 sec)

# Activate all roles associated with this user using SET ROLE.
# You can activate specific roles or all roles.
# In this case, the user only has 2 roles, so we specify ALL.
 > SET ROLE ALL;
Query OK, 0 rows affected (0.00 sec)

# Verify role is now active
 > SELECT CURRENT_ROLE();
+--------------------------------------------------+
| CURRENT_ROLE()                                   |
+--------------------------------------------------+
| `AWS_LAMBDA_ACCESS`@`%`,`rds_superuser_role`@`%` |
+--------------------------------------------------+

Authentication

在社群 MySQL 8.0 中，原定设置的身份验证插件是 caching_sha2_password。Aurora MySQL 版本 3 仍然使用 mysql_native_password 插件。您将无法更改 default_authentication_plugin 设置。

Aurora MySQL 版本 3 的升级计划

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

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

目前，从早期的 Aurora MySQL 版本到 Aurora MySQL 版本 3 的主要升级路径是恢复快照以创建新集群。您可以将运行任何次要版本的 Aurora MySQL 版本 2（与 MySQL 5.7）的集群的快照还原到 Aurora MySQL 版本 3。要从 Aurora MySQL 版本 1 进行升级，请使用两步过程。首先将快照还原到 Aurora MySQL 版本 2 集群，然后创建该集群的快照并将其还原到 Aurora MySQL 版本 3 集群。有关从 Aurora MySQL 版本 1 或 2 的升级过程，请参阅 升级到 Aurora MySQL 版本 3。有关通过还原快照进行升级的一般信息，请参阅 升级 Amazon Aurora MySQL 数据库集群。

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

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

升级到 Aurora MySQL 版本 3

对于将数据库从 Aurora MySQL 版本 1 或 2 升级到版本 3 的特定升级路径，可以使用以下方法之一：

从 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.10.0",
    "5.7.mysql_aurora.2.10.1",
    "8.0.mysql_aurora.3.01.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.01.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-restored",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.01.0",
  "Status": "creating"
}

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

$ 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.01.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.01.0

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

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

从 Aurora MySQL 版本 1 升级到版本 3 的示例

以下示例显示了如果原始快照来自无法直接还原到 Aurora MySQL 版本 3 的版本，则分两阶段的升级过程。相反，该快照将还原到运行中间版本的集群中，您可以将其升级到 Aurora MySQL 版本 3。此中间集群不需要任何关联的数据库实例。然后，从中间集群创建另一个快照。最后，还原第二个快照以创建新的 Aurora MySQL 版本 3 集群和写入器数据库实例。

我们开始使用的 Aurora MySQL 版本 1 集群被命名为 aurora-mysql-v1-to-v2。它运行的是 Aurora MySQL 版本 1.23.4。该集群至少包含一个数据库实例。

此示例检查哪些 Aurora MySQL 版本 2 版本可以升级到 8.0.mysql_aurora.3.01.0 以在升级后的集群上使用。在此示例中，我们选择版本 2.10.0 作为中间版本。

$ aws rds describe-db-engine-versions --engine aurora-mysql \
  --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} |
    [?contains(TargetVersions, `'8.0.mysql_aurora.3.01.0'`) == `true`]|[].EngineVersion' \
  --output text
...
5.7.mysql_aurora.2.08.3
5.7.mysql_aurora.2.09.1
5.7.mysql_aurora.2.09.2
5.7.mysql_aurora.2.10.0
...

以下示例验证 Aurora MySQL 版本 1.23.4 至 2.10.0 版本是否为可用的升级路径。因此，我们运行的 Aurora MySQL 版本可以升级到 2.10.0。然后，该集群可以升级到 3.01.0。

aws rds describe-db-engine-versions --engine aurora \
  --query '*[].{EngineVersion:EngineVersion,TargetVersions:ValidUpgradeTarget[*].EngineVersion} |
    [?contains(TargetVersions, `'5.7.mysql_aurora.2.10.0'`) == `true`]|[].[EngineVersion]' \
  --output text
...
5.6.mysql_aurora.1.22.5
5.6.mysql_aurora.1.23.0
5.6.mysql_aurora.1.23.1
5.6.mysql_aurora.1.23.2
5.6.mysql_aurora.1.23.3
5.6.mysql_aurora.1.23.4
...

以下示例将创建一个名为 aurora-mysql-v1-to-v2-snapshot 的快照，该快照基于原始的 Aurora MySQL 版本 1 集群。

$ aws rds create-db-cluster-snapshot \
  --db-cluster-id aurora-mysql-v1-to-v2 \
  --db-cluster-snapshot-id aurora-mysql-v1-to-v2-snapshot
{
  "DBClusterSnapshotIdentifier": "aurora-mysql-v1-to-v2-snapshot",
  "DBClusterIdentifier": "aurora-mysql-v1-to-v2"
}

以下示例从版本 1 快照创建中间 Aurora MySQL 版本 2 集群。此中间集群名为 aurora-mysql-v2-to-v3。它运行的是 Aurora MySQL 版本 2.10.0。

该示例还为集群创建了一个写入器实例。为了使升级过程正常运行，此中间集群需要一个写入器实例。

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id aurora-mysql-v1-to-v2-snapshot \
  --db-cluster-id aurora-mysql-v2-to-v3 \
  --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
    "DBCluster": {
        "AllocatedStorage": 1,
        "AvailabilityZones": [
            "us-east-1a",
            "us-east-1d",
            "us-east-1f"
        ],
...

$ aws rds create-db-instance --db-instance-identifier upgrade-demo-instance \
  --db-cluster-identifier aurora-mysql-v2-to-v3 \
  --db-instance-class db.r5.xlarge \
  --engine aurora-mysql
{
  "DBInstanceIdentifier": "upgrade-demo-instance",
  "DBInstanceClass": "db.r5.xlarge",
  "DBInstanceStatus": "creating"
}

以下示例从中间 Aurora MySQL 版本 2 集群创建快照。此快照名为 aurora-mysql-v2-to-v3-snapshot。它是为了创建 Aurora MySQL 版本 3 集群而要还原的快照。

$ aws rds create-db-cluster-snapshot \
  --db-cluster-id aurora-mysql-v2-to-v3 \
  --db-cluster-snapshot-id aurora-mysql-v2-to-v3-snapshot
{
  "DBClusterSnapshotIdentifier": "aurora-mysql-v2-to-v3-snapshot",
  "DBClusterIdentifier": "aurora-mysql-v2-to-v3"
}

以下命令将创建 Aurora MySQL 版本 3 集群。此集群名为 aurora-mysql-v3-fully-upgraded。

$ aws rds restore-db-cluster-from-snapshot \
  --snapshot-id aurora-mysql-v2-to-v3-snapshot \
  --db-cluster-id aurora-mysql-v3-fully-upgraded \
  --engine aurora-mysql --engine-version 8.0.mysql_aurora.3.01.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
    "DBCluster": {
        "AllocatedStorage": 1,
        "AvailabilityZones": [
            "us-east-1b",
            "us-east-1c",
            "us-east-1d"
        ],
...

现在已创建了 Aurora MySQL 版本 3 集群，下面的示例为其创建了一个写入器数据库实例。当集群和写入器实例变为可用时，您可以连接到集群并开始使用它。来自原始集群的所有数据都会在每个快照阶段保留。

$ aws rds create-db-instance \
  --db-instance-identifier instance-also-running-v3 \
  --db-cluster-identifier aurora-mysql-v3-fully-upgraded \
  --db-instance-class db.r5.xlarge --engine aurora-mysql
{
  "DBInstanceIdentifier": "instance-also-running-v3",
  "DBClusterIdentifier": "aurora-mysql-v3-fully-upgraded",
  "DBInstanceClass": "db.r5.xlarge",
  "EngineVersion": "8.0.mysql_aurora.3.01.0",
  "DBInstanceStatus": "creating"
}

Aurora MySQL 版本 3 的升级后清理

将任何 Aurora MySQL 版本 1 或 2 集群升级到 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 中的变化。