来自社群 MySQL 8.0 的功能新的并行查询优化发布说明比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3 比较 Aurora MySQL 版本 3 和社群 MySQL 8.0 升级到 Aurora MySQL 版本 3

与 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 的发布说明
比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3
比较 Aurora MySQL 版本 3 和社群 MySQL 8.0
升级到 Aurora MySQL 版本 3

来自社群 MySQL 8.0 的功能

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

JSON 函数。有关使用信息，请参阅 MySQL 参考手册中的 JSON 函数。
窗口函数。有关使用信息，请参阅 MySQL 参考手册中的 Window 函数。
使用 WITH 子句的公用表表达式 (CTE)。有关使用信息，请参阅 MySQL 参考手册中的 WITH（公用表表达式）。
ALTER TABLE 语句的优化 ADD COLUMN 和 RENAME COLUMN 子句。这些优化被称为“即时 DDL”。Aurora MySQL 版本 3 与社群 MySQL 即时 DDL 功能兼容。未使用以前的 Aurora 快速 DDL 功能。有关即时 DDL 的使用信息，请参阅即时 DDL（Aurora MySQL 版本 3）。
降序、功能性和不可见的索引。有关使用信息，请参阅 MySQL 参考手册中的不可见索引、降序索引和 CREATE INDEX 语句。
通过 SQL 语句控制的基于角色的权限。有关更改权限模型的更多信息，请参阅基于角色的权限模型。
带有 SELECT ... FOR SHARE 语句的 NOWAIT 和 SKIP LOCKED 子句。这些子句避免了等待其他事务释放行锁。有关使用信息，请参阅 MySQL 参考手册中的锁定读取。
改进二进制日志 (binlog) 复制。有关 Aurora MySQL 的详细信息，请参阅二进制日志复制。特别是，您可以执行筛选的复制。有关筛选复制的使用信息，请参阅 MySQL 参考手册中的服务器如何评估复制筛选规则。
提示。一些 MySQL 8.0 兼容的提示已被向后移植到 Aurora MySQL 版本 2。有关将提示用于 Aurora MySQL 的信息，请参阅 Aurora MySQL 提示。有关社群 MySQL 8.0 中的完整提示列表，请参阅 MySQL 参考手册中的优化程序提示。

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

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

新的并行查询优化

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

并行查询现在适用于包含数据类型 TEXT、BLOB、JSON、GEOMETRY 和 VARCHAR 以及超过 768 个字节的 CHAR 的表。
并行查询可以优化涉及分区表的查询。
并行查询可以优化涉及选择列表中聚合函数调用的查询和 HAVING 子句。

有关这些增强功能的更多信息，请参阅将并行查询集群升级到 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 版本 3 的参数更改
状态变量
Aurora MySQL 版本 3 的包容性语言更改
AUTO_INCREMENT 值
读取器数据库实例上的临时表
内部临时表的存储引擎
二进制日志复制

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

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

目前，回溯追踪不适用于 Aurora MySQL 版本 3 集群。我们打算在后续的次要版本中提供此功能。

如果您有一个使用回溯的 Aurora MySQL 版本 2 集群，那么目前您无法使用快照还原方法升级到 Aurora MySQL 版本 3。此限制适用于使用回溯集群的所有集群，无论回溯设置是否已启用。有关升级过程的详细信息，请参阅升级到 Aurora MySQL 版本 3。
您不能将 Aurora MySQL 版本 3 用于 Aurora Serverless v1 集群。Aurora MySQL 版本 3 可以与 Aurora Serverless v2 结合使用，目前处在预览中。
实验室模式不适用于 Aurora MySQL 版本 3。Aurora MySQL 版本 3 中没有任何实验室模式功能。即时 DDL 取代了以前在实验室模式下可用的快速线上 DDL 功能。有关示例，请参阅即时 DDL（Aurora MySQL 版本 3）。
查询缓存已从社群 MySQL 8.0 以及 Aurora MySQL 版本 3 中删除。
Aurora MySQL 版本 3 与社群 MySQL 即时哈希联接功能兼容。未使用 Aurora MySQL 版本 2 中特定于 Aurora 的哈希联接实现。有关在 Aurora 并行查询中使用哈希联接的信息，请参阅为并行查询集群开启哈希联接和 Aurora MySQL 提示。有关哈希联接的一般用法信息，请参阅 MySQL 参考手册中的哈希联接优化。
目前，您无法将物理备份从 Percona XtraBackup 工具还原到 Aurora MySQL 版本 3 集群。我们打算在后续的次要版本中支持此功能。
在 Aurora MySQL 版本 2 中弃用的 mysql.lambda_async 存储过程将在版本 3 中删除。对于版本 3，请使用异步函数 lambda_async。
Aurora MySQL 版本 3 中的原定设置字符集是 utf8mb4。Aurora MySQL 版本 2 中的原定设置字符集是 latin1。有关此字符集的信息，请参阅 MySQL 参考手册中的 utf8mb4 字符集（4 字节 UTF-8 Unicode 编码）。
innodb_flush_log_at_trx_commit 配置参数无法修改。原定设置值 1 始终适用。

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

实例类支持

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

对于较大的实例，您可以使用现代实例类，例如 db.r5、db.r6g 和 db.x2g。
对于较大的实例，您可以使用现代实例类，例如 db.t3 和 db.t4g。

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

db.r4
db.r3
db.t3.small
db.t2

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

提示

检查可用于 Aurora MySQL 版本和 Amazon 区域特定组合的实例类，请使用 describe-orderable-db-instance-options Amazon CLI 命令。

有关 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 时，请务必更新依赖指标名称的任何告警或其他自动化。

旧名称	新名称
`ForwardingMasterDMLLatency`	`ForwardingWriterDMLLatency`
`ForwardingMasterOpenSessions`	`ForwardingWriterOpenSessions`
`AuroraDMLRejectedMasterFull`	`AuroraDMLRejectedWriterFull`
`ForwardingMasterDMLThroughput`	`ForwardingWriterDMLThroughput`

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

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

要删除的名称	新名称或首选名称
`Aurora_fwd_master_dml_stmt_duration`	`Aurora_fwd_writer_dml_stmt_duration`
`Aurora_fwd_master_dml_stmt_count`	`Aurora_fwd_writer_dml_stmt_count`
`Aurora_fwd_master_select_stmt_duration`	`Aurora_fwd_writer_select_stmt_duration`
`Aurora_fwd_master_select_stmt_count`	`Aurora_fwd_writer_select_stmt_count`
`Aurora_fwd_master_errors_session_timeout`	`Aurora_fwd_writer_errors_session_timeout`
`Aurora_fwd_master_open_sessions`	`Aurora_fwd_writer_open_sessions`
`Aurora_fwd_master_errors_session_limit`	`Aurora_fwd_writer_errors_session_limit`
`Aurora_fwd_master_errors_rpc_timeout`	`Aurora_fwd_writer_errors_rpc_timeout`

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

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

要删除的名称	新名称或首选名称
`aurora_fwd_master_idle_timeout`	`aurora_fwd_writer_idle_timeout`
`aurora_fwd_master_max_connections_pct`	`aurora_fwd_writer_max_connections_pct`
`master_verify_checksum`	`source_verify_checksum`
`sync_master_info`	`sync_source_info`
`init_slave`	`init_replica`
`rpl_stop_slave_timeout`	`rpl_stop_replica_timeout`
`log_slow_slave_statements`	`log_slow_replica_statements`
`slave_max_allowed_packet`	`replica_max_allowed_packet`
`slave_compressed_protocol`	`replica_compressed_protocol`
`slave_exec_mode`	`replica_exec_mode`
`slave_type_conversions`	`replica_type_conversions`
`slave_sql_verify_checksum`	`replica_sql_verify_checksum`
`slave_parallel_type`	`replica_parallel_type`
`slave_preserve_commit_order`	`replica_preserve_commit_order`
`log_slave_updates`	`log_replica_updates`
`slave_allow_batching`	`replica_allow_batching`
`slave_load_tmpdir`	`replica_load_tmpdir`
`slave_net_timeout`	`replica_net_timeout`
`sql_slave_skip_counter`	`sql_replica_skip_counter`
`slave_skip_errors`	`replica_skip_errors`
`slave_checkpoint_period`	`replica_checkpoint_period`
`slave_checkpoint_group`	`replica_checkpoint_group`
`slave_transaction_retries`	`replica_transaction_retries`
`slave_parallel_workers`	`replica_parallel_workers`
`slave_pending_jobs_size_max`	`replica_pending_jobs_size_max`
`pseudo_slave_mode`	`pseudo_replica_mode`

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

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

要删除的名称	新名称或首选名称
`mysql.rds_set_master_auto_position`	`mysql.rds_set_source_auto_position`
`mysql.rds_set_external_master`	`mysql.rds_set_external_source`
`mysql.rds_set_external_master_with_auto_position`	`mysql.rds_set_external_source_with_auto_position`
`mysql.rds_reset_external_master`	`mysql.rds_reset_external_source`
`mysql.rds_next_master_log`	`mysql.rds_next_source_log`

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 内存池或者只有少量溢出内存池。在这些情况下，我们建议将 TempTable 设置用于内部临时表和内存映射文件以保存任何溢出数据。该设置为原定设置。

如果大量临时数据溢出 TempTable 内存池，我们建议将 MEMORY 存储引擎用于内部临时表。或者，您也可以选择将 TempTable 用于内部临时表和 InnoDB 表来保存任何溢出数据。

您首先在 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 存储溢出数据的方式不同，具体取决于您选择的数据溢出目标以及查询是在写入器还是读取器数据库实例上运行：

在写入器实例上，溢出到 InnoDB 内部临时表的数据存储在 Aurora 集群卷中。
在写入器实例上，溢出到内存映射临时文件的数据驻留在 Aurora MySQL 版本 3 实例上的本地存储中。
在读取器实例上，溢出数据始终驻留在本地存储上的内存映射临时文件上。这是因为只读实例无法在 Aurora 集群卷上存储任何数据。

注意

与内部临时表相关的配置参数对集群中的写入器和读取器实例的应用方式不同。对于读取器实例，Aurora MySQL 始终将 TempTable 存储引擎和值 1 用于 temptable_use_mmap。对于写入器和读取器实例，temptable_max_mmap 的大小都原定设置为 1GB，无论数据库实例内存大小如何。您可以按照写入器实例上的相同方式调整此值，只是不能为读取器实例上的 temptable_max_mmap 指定零值。

二进制日志复制

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

提示

如果 Aurora 内置复制功能满足了您的高可用性要求，则可以关闭二进制日志复制。这样，您就可以避免二进制日志复制的性能开销。您还可以避免管理二进制日志复制所需的相关监控和故障排除过程。

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 及更高版本）。

注意

我们仍建议不要将多线程复制与 Aurora MySQL 版本 1 和版本 2 结合使用。

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

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

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

无论是否启用 Aurora MySQL 二进制日志压缩设置，其二进制日志数据大于允许的最大数据包大小的事务都不会压缩。此类事务在不被压缩的情况下被复制。
如果您使用尚不支持 MySQL 8.0 的更改数据捕获 (CDC) 的连接器，则无法使用此功能。我们建议在对 CDC 使用二进制日志复制的系统上启用二进制日志压缩之前，先使用二进制日志压缩彻底测试任何第三方连接器。

比较 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 中不可用

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

Aurora MySQL 不支持资源组和相关的 SQL 语句。
Aurora 存储架构意味着您不必手动管理数据库的文件和底层存储。特别是，Aurora 处理撤消表空间的方式与社群 MySQL 的方式不同。这种与社群 MySQL 的区别具有以下结果：
- Aurora MySQL 不支持命名的表空间。
- innodb_undo_log_truncate 配置设置已关闭且无法打开。Aurora 拥有自己的回收存储空间的机制。
- Aurora MySQL 没有 CREATE UNDO TABLESPACE、ALTER UNDO TABLESPACE ... SET INACTIVE 和 DROP UNDO TABLESPACE 语句。
- Aurora 会自动设置撤消表空间的数量，并为您管理这些表空间。
Aurora MySQL 版本 3 不支持 TLS 1.3。
aurora_hot_page_contention 状态变量不可用。不支持热页面争用功能。有关 Aurora MySQL 版本 3 不提供的状态变量的完整列表，请参阅状态变量。
您无法修改任何 MySQL 插件的设置。
不支持 X 插件。

基于角色的权限模型

使用 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 角色包括所有数据库对象的以下权限：

ALTER
APPLICATION_PASSWORD_ADMIN
ALTER ROUTINE
CONNECTION_ADMIN
CREATE
CREATE ROLE
CREATE ROUTINE
CREATE TABLESPACE
CREATE TEMPORARY TABLES
CREATE USER
CREATE VIEW
DELETE
DROP
DROP ROLE
EVENT
EXECUTE
INDEX
INSERT
LOCK TABLES
PROCESS
REFERENCES
RELOAD
REPLICATION CLIENT
REPLICATION SLAVE
ROLE_ADMIN
SET_USER_ID
SELECT
SHOW DATABASES
SHOW VIEW
TRIGGER
UPDATE
XA_RECOVER_ADMIN

角色定义还包括 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 服务相关的角色：

AWS_LAMBDA_ACCESS 角色，作为 INVOKE LAMBDA 权限的替代。有关使用信息，从 Amazon Aurora MySQL 数据库集群中调用 Lambda 函数。
AWS_LOAD_S3_ACCESS 角色，作为 LOAD FROM S3 权限的替代。有关使用信息，请参阅将数据从 Amazon S3 存储桶中的文本文件加载到 Amazon Aurora MySQL 数据库集群。
AWS_SELECT_S3_ACCESS 角色，作为 SELECT INTO S3 权限的替代。有关使用信息，请参阅将数据从 Amazon Aurora MySQL 数据库集群保存到 Amazon S3 存储桶中的文本文件。
AWS_SAGEMAKER_ACCESS 角色，作为 INVOKE SAGEMAKER 权限的替代。有关使用信息，请参阅将 Machine Learning (ML) 与 Aurora MySQL 结合使用。
AWS_COMPREHEND_ACCESS 角色，作为 INVOKE COMPREHEND 权限的替代。有关使用信息，请参阅将 Machine Learning (ML) 与 Aurora MySQL 结合使用。

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


# Grant role to user
mysql> 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.
mysql> 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.
mysql> SET ROLE ALL;
Query OK, 0 rows affected (0.00 sec)

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

身份验证

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

升级到 Aurora MySQL 版本 3

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

要将 Aurora MySQL 版本 2 集群升级到版本 3，请创建版本 2 集群的快照并恢复快照以创建新的版本 3 集群。按照从数据库集群快照还原中的过程操作。目前，无法进行从 Aurora MySQL 版本 2 到 Aurora MySQL 版本 3 的就地升级。
要从 Aurora MySQL 版本 1 进行升级，首先进行到 Aurora MySQL 版本 2 的中间升级。要升级到 Aurora MySQL 版本 2，请使用升级 Amazon Aurora MySQL 数据库集群中的任何升级方法。然后使用快照还原技术将 Aurora MySQL 版本 2 升级到 Aurora MySQL 版本 3。无法进行从 Aurora MySQL 版本 1 集群（与 MySQL 5.6 兼容）到 Aurora MySQL 版本 3 的快照还原。
目前，您无法将与 MySQL 5.7 兼容 Aurora 集群克隆到与 MySQL 8.0 兼容的集群。改用快照还原技术。
如果您有一个使用回溯的 Aurora MySQL 版本 2 集群，那么目前您无法使用快照还原方法升级到 Aurora MySQL 版本 3。此限制适用于使用回溯的所有集群，无论回溯设置是否已启用。在这种情况下，请使用 mysqldump 命令之类的工具执行逻辑转储和还原。有关将 mysqldump 用于 Aurora MySQL 的更多信息，请参阅使用 mysqldump 从 MySQL 迁移到 Amazon Aurora。

提示

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

主题

Aurora MySQL 版本 3 的升级计划
从 Aurora MySQL 版本 2 升级到版本 3 的示例
从 Aurora MySQL 版本 1 升级到版本 3 的示例
排查 Aurora MySQL 版本 3 升级问题
Aurora MySQL 版本 3 的升级后清理

Aurora MySQL 版本 3 的升级计划

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

如果您要从 RDS for MySQL 或社群 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 参数的任何更改不会产生任何影响。

您还可以在 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 版本 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 实例类创建一个写入器数据库实例。

提示

您可能拥有使用 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.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 版本 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 \
  --master-user-password my_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 索引再删除索引，会遗留一些在升级期间导致问题的元数据。


$ 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.01.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-attempt-1",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.01.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.01.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: Oscar PreChecker Found 1 errors",
            "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.01.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."
}

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

首先，返回原始集群并创建一个新表，其结构和内容与错误元数据相同。实际上，您可能会在升级后将此表重命名为原始表名。


$ 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.01.0 \
  --enable-cloudwatch-logs-exports '["error","general","slowquery","audit"]'
{
  "DBClusterIdentifier": "cluster-80-attempt-2",
  "Engine": "aurora-mysql",
  "EngineVersion": "8.0.mysql_aurora.3.01.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.01.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.01.0
$ aws rds describe-db-instances \
  --db-instance-identifier instance-attempt-2 \
  --query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.01.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 版本 1 或 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 中的变化。

Javascript 在您的浏览器中被禁用或不可用。

要使用 Amazon Web Services 文档，必须启用 Javascript。请参阅浏览器的帮助页面以了解相关说明。

Aurora MySQL 概述

与 MySQL 5.7 兼容的 Aurora MySQL 版本 2