Aurora MySQL 数据库引擎更新 2020-09-17（版本 2.09.0）（已弃用） - Amazon Aurora
改进集成了 MySQL 社区版本错误修复与 Aurora MySQL 版本 1 进行比较MySQL 5.7 兼容性
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

Aurora MySQL 数据库引擎更新 2020-09-17（版本 2.09.0）（已弃用）

版本：2.09.0

Aurora MySQL 2.09.0 已正式发布。Aurora MySQL 2.x 版与 MySQL 5.7 兼容，Aurora MySQL 1.x 版与 MySQL 5.6 兼容。

当前支持的 Aurora MySQL 版本有 1.19.5、1.19.6、1.22.*、1.23.*、2.04.*、2.07.*、2.08.*、2.09.*、2.10.*、3.01.* 和 3.02.*。

您可以将快照从 Aurora MySQL 1.23.* 还原到 Aurora MySQL 2.09.0。您还可以选择将现有 Aurora MySQL 2.* 数据库集群升级到 Aurora MySQL 2.09.0。不能将现有的 Aurora MySQL 1.23.* 集群直接升级到 2.09.0，但是可以将其快照还原到 Aurora MySQL 2.09.0。

重要

此版本中对 Aurora 存储的改进将可用升级路径限制为从 Aurora MySQL 1.* 到 Aurora MySQL 2.09.. 将 Aurora MySQL 1.* 集群升级到 2.09 时，您必须从 Aurora MySQL 1.23 升级。

要使用较旧版本的 Aurora MySQL 创建集群，请通过Amazon Web Services Management Console 、Amazon CLI 或 RDS API 指定引擎版本。

如果您有任何问题或疑问，可通过社区论坛和 Amazon Support 联系 Amazon Support。有关更多信息，请参阅《Amazon Aurora 用户指南》中的维护 Amazon Aurora 数据库集群。

注意

有关如何升级 Aurora MySQL 数据库集群的信息，请参阅《Amazon Aurora 用户指南》中的升级 Aurora MySQL 数据库集群的次要版本或补丁程序级别。

改进

新功能：

  • 通过此版本，您可以创建具有最多 128 TiB 存储空间的 Amazon Aurora MySQL 数据库实例。新的存储空间限制比之前的 64 TiB 有所增加。128 TiB 存储大小支持更大的数据库。小型实例大小（db.t2 或 db.t3）不支持此功能。由于 InnoDB 具有页面大小为 16 KB 的限制，因此单个表空间无法增长到 64 TiB 以上。

    当集群卷大小接近 128 TiB 时，Aurora 发出警报，以便您可以在达到大小限制之前采取措施。警报显示在 mysql 日志和 Amazon Web Services Management Console的 RDS 事件中。

  • 现在，您可以通过更改数据库集群参数 aurora_parallel_query 的值来为现有集群打开或关闭并行查询。创建集群时，不需要使用 parallelquery 参数的 --engine-mode 设置。

    并行查询现在已扩展到 Aurora MySQL 可用的所有区域。

    对于在 Aurora 集群中升级和启用并行查询的过程，还有许多其他功能增强和更改。有关更多信息，请参阅《Amazon Aurora 用户指南》中的使用 Amazon Aurora MySQL 的并行查询。

  • Aurora 动态调整集群存储空间的大小。通过动态调整大小，当您从 Aurora 数据库集群中删除数据时，该数据库集群的存储空间会自动减少。有关更多信息，请参阅《Amazon Aurora 用户指南》中的存储扩展。

    注意

    动态调整大小功能正在分阶段部署到 Aurora 可用的Amazon区域。根据集群所在的区域，此功能可能尚不可用。有关更多信息，请参阅新增功能公告。

高优先级修复：

  • 逆向移植社区错误 #27659490：SELECT USING DYNAMIC RANGE AND INDEX MERGE USE TOO MUCH MEMORY (OOM)

  • 错误 #26881508：MYSQL #1: DISABLE_ABORT_ON_ERROR IN AUTH_COMMON.H

  • 逆向移植社区错误 #24437124：POSSIBLE BUFFER OVERFLOW ON CREATE TABLE

  • 逆向移植错误 #27158030：INNODB ONLINE ALTER CRASHES WITH CONCURRENT DML

  • 错误 #29770705：SERVER CRASHED WHILE EXECUTING SELECT WITH SPECIFIC WHERE CLAUSE

  • 逆向移植错误 #26502135：MYSQLD SEGFAULTS IN MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL

  • 逆向移植社区错误 #26935001：ALTER TABLE AUTO_INCREMENT TRIES TO READ INDEX FROM DISCARDED TABLESPACE

  • 错误 #28491099：[FATAL] MEMORY BLOCK IS INVALID | INNODB: ASSERTION FAILURE: UT0UT.CC:670

  • 错误 #30499288：GCC 9.2.1 REPORTS A NEW WARNING FOR OS_FILE_GET_PARENT_DIR

  • 错误 #29952565，其中 MYSQLD GOT SIGNAL 11 WHILE EXECUTING A QUERY(UNION + ORDER BY + SUB-QUERY)

  • 错误 #30628268：OUT OF MEMORY CRASH

  • 错误 #30441969：错误 #29723340：MYSQL SERVER CRASH AFTER SQL QUERY WITH DATA ?AST

  • 错误 #30569003：5.7 REPLICATION BREAKAGE WITH SYNTAX ERROR WITH GRANT MANAGEMENT

  • 错误 #29915479：RUNNING COM_REGISTER_SLAVE WITHOUT COM_BINLOG_DUMP CAN RESULTS IN SERVER EXIT

  • 错误 #30569003：5.7 REPLICATION BREAKAGE WITH SYNTAX ERROR WITH GRANT MANAGEMENT

  • 错误 #29915479：RUNNING COM_REGISTER_SLAVE WITHOUT COM_BINLOG_DUMP CAN RESULTS IN SERVER EXIT

  • 错误 #20712046：SHOW PROCESSLIST AND PERFORMANCE_SCHEMA TABLES DO NOT MASK PASSWORD FROM QUERY

  • 逆向移植错误 #18898433：EXTREMELY SLOW PERFORMANCE WITH OUTER JOINS AND JOIN BUFFER（在 5.7.21 中已修复）。在使用联接缓冲（例如，使用块嵌套循环算法）的情况下，带有许多左联接的查询会很慢。（错误 #18898433、错误 #72854）

  • 逆向移植错误 #26402045：MYSQLD CRASHES ON QUERY（在 MySQL 5.7.23 中已修复）。某些情况下的子查询具体化可能会导致服务器退出。这些查询现在会产生建议禁止具体化的错误。（错误 #26402045）

  • [从 MySQL 逆向移植] 不允许 rdsadmin 以外的用户更新读取器副本中的 pfs 表。

  • 修复客户无法更新读取器副本中的 perfschema 的问题

  • 错误 #26666274：性能架构缓冲区容器中的无限循环

  • 错误 #26997096：relay_log_space 值不以同步的方式更新，因此其值有时大大高于中继日志使用的实际磁盘空间。

  • 错误 #25082593：FOREIGN KEY VALIDATION DOESN'T NEED TO ACQUIRE GAP LOCK IN READ COMMITTED

  • CVE-2019-2731

  • CVE-2018-2645

  • CVE-2019-2581

  • CVE-2018-2787

  • CVE-2019-2482

  • CVE-2018-2640

  • CVE-2018-2784

  • CVE-2019-2628

  • CVE-2019-2911

  • CVE-2019-2628

  • CVE-2018-3284

  • CVE-2018-3065

  • CVE-2019-2537

  • CVE-2019-2948

  • CVE-2019-2434

  • CVE-2019-2420

可用性改进：

  • 默认情况下启用锁定管理器 ABA 修复。

  • 修复了锁管理器中的一个问题，其中，竞争条件可能导致两个事务共享一个锁，从而导致数据库重新启动。

  • 修复了使用压缩行格式创建临时表时可能导致重新启动的问题。

  • 修复 16XL 和 24XL 实例上 table_open_cache 的默认值，此值可能导致在大型实例类（R4/R5-16XL、R5-12XL、R5-24XL）上发生重复的故障转移和较高的 CPU 利用率。这影响了 2.07.x。

  • 修复了以下问题：当 S3 备份不包含 mysql.host 表时，将集群从 Amazon S3 还原到 Aurora MySQL 版本 2.08.0 所需时间比预期时间长。

  • 修复了由于更新具有二级索引的虚拟列而可能导致重复故障转移的问题。

  • 修复了一个与事务锁内存管理（即，长时间运行的写事务导致数据库重新启动）相关的问题。

  • 修复了在检查安全点以进行修补时，引擎可能会在零停机时间修补过程中崩溃的多个问题。

  • 修复了跳过临时表的重做日志记录的问题，此问题之前导致崩溃。

  • 修复了锁管理器中终止连接/查询与已终止会话之间的竞争条件。

  • 修复了以下问题：如果数据库是二进制日志副本并通过 MySQL time_zone 表接收 DDL 事件，则此数据库可能会崩溃。

全局数据库：

  • 辅助区域中的 MySQL INFORMATION_SCHEMA.REPLICA_HOST_STATUS 视图现在显示属于该区域的副本的条目。

  • 修复了若干个意外查询失败：在主区域和辅助区域之间发生临时网络连接问题之后，导致在全局数据库辅助区域中可能发生这些意外查询失败。

并行查询：

  • 修复了并行查询的 EXPLAIN 计划，这对于简单的单表查询是不正确的。

  • 修复了启用并行查询时可能发生的自死锁。

常规改进：

  • 导出到 S3 现在支持 ENCRYPTION 关键字。

  • aurora_binlog_replication_max_yield_seconds 参数现在的最大值为 36,000。之前接受的最大值为 45。仅当参数 aurora_binlog_use_large_read_buffer 设置为 1 时，此参数才有效。

  • 已将执行 MIXED 时的行为更改为将 binlog_format ROW 映射到 STATEMENT，而不是映射到 LOAD DATA FROM INFILE | S3。

  • 修复了以下问题：当主服务器执行了 LOAD DATA FROM S3 且 binlog_format 设置为 STATEMENT 时，连接到 Aurora MySQL 二进制日志主服务器的二进制日志副本可能显示不完整的数据。

  • 已将审计系统变量 server_audit_incl_users 和 server_audit_excl_users 允许的最大长度从 1024 字节增加到 2000 字节。

  • 修复了以下问题：如果当前连接数大于设置的值，在降低参数组中的 max_connections 参数时，用户可能会失去对数据库的访问权限。

  • 修复了数据活动流中单引号和反斜杠未正确转义的问题。

集成了 MySQL 社区版本错误修复

  • 错误 #27659490：SELECT USING DYNAMIC RANGE AND INDEX MERGE USE TOO MUCH MEMORY(OOM)

  • 错误 #26881508：MYSQL #1: DISABLE_ABORT_ON_ERROR IN AUTH_COMMON.H

  • 错误 #24437124：POSSIBLE BUFFER OVERFLOW ON CREATE TABLE

  • 错误 #27158030：INNODB ONLINE ALTER CRASHES WITH CONCURRENT DML

  • 错误 #29770705：SERVER CRASHED WHILE EXECUTING SELECT WITH SPECIFIC WHERE CLAUSE

  • 错误 #26502135：MYSQLD SEGFAULTS IN MDL_CONTEXT::TRY_ACQUIRE_LOCK_IMPL

  • 错误 #26935001：ALTER TABLE AUTO_INCREMENT TRIES TO READ INDEX FROM DISCARDED TABLESPACE

  • 错误 #28491099：[FATAL] MEMORY BLOCK IS INVALID | INNODB: ASSERTION FAILURE: UT0UT.CC:670

  • 错误 #30499288：GCC 9.2.1 REPORTS A NEW WARNING FOR OS_FILE_GET_PARENT_DIR

  • 错误 #29952565：其中 MYSQLD GOT SIGNAL 11 WHILE EXECUTING A QUERY(UNION + ORDER BY + SUB-QUERY)

  • 错误 #30628268：OUT OF MEMORY CRASH

  • 错误 #30441969：错误 #29723340：MYSQL SERVER CRASH AFTER SQL QUERY WITH DATA ?AST

  • 错误 #30569003：5.7 REPLICATION BREAKAGE WITH SYNTAX ERROR WITH GRANT MANAGEMENT

  • 错误 #29915479：RUNNING COM_REGISTER_SLAVE WITHOUT COM_BINLOG_DUMP CAN RESULTS IN SERVER EXIT

  • 错误 #30569003：5.7 REPLICATION BREAKAGE WITH SYNTAX ERROR WITH GRANT MANAGEMENT

  • 错误 #29915479：RUNNING COM_REGISTER_SLAVE WITHOUT COM_BINLOG_DUMP CAN RESULTS IN SERVER EXIT

  • 错误 #20712046：SHOW PROCESSLIST AND PERFORMANCE_SCHEMA TABLES DO NOT MASK PASSWORD FROM QUERY

  • 错误 #18898433：EXTREMELY SLOW PERFORMANCE WITH OUTER JOINS AND JOIN BUFFER（在 5.7.21 中已修复）

  • 错误 #26402045：MYSQLD CRASHES ON QUERY（在 MySQL 5.7.23 中已修复）

  • 错误 #23103937：PS_TRUNCATE_ALL_TABLES() 在 SUPER_READ_ONLY 模式下无法运行

  • 错误 #26666274：性能架构缓冲区容器中的无限循环

  • 错误 #26997096：relay_log_space 值不以同步的方式更新，因此其值有时大大高于中继日志使用的实际磁盘空间。 (https://github.com/mysql/mysql-server/commit/78f25d2809ad457e81f90342239c9bc32a36cdfa)

  • 错误 #25082593：FOREIGN KEY VALIDATION DOESN'T NEED TO ACQUIRE GAP LOCK IN READ COMMITTED

  • 错误 #24764800：REPLICATION FAILING ON SLAVE WITH XAER_RMFAIL ERROR。

  • 错误 #81441：WARNING ABOUT LOCALHOST WHEN USING SKIP-NAME-RESOLVE。

与 Aurora MySQL 版本 1 进行比较

以下 Amazon Aurora MySQL 功能在 Aurora MySQL 版本 1（兼容 MySQL 5.6）中受支持，但这些功能目前在 Aurora MySQL 版本 2（兼容 MySQL 5.7）中不受支持。

MySQL 5.7 兼容性

此 Aurora MySQL 版本与 MySQL 5.7 数据兼容，包含 JSON 支持、空间索引及生成列等功能。Aurora MySQL 使用 Z 阶曲线原生实现了空间索引功能，使空间数据集的写入性能相比于 MySQL 5.7 提高了 20 倍以上，读取性能提高 10 倍以上。

此 Aurora MySQL 版本当前不支持以下 MySQL 5.7 功能：

  • 组复制插件

  • 增加的页面大小

  • InnoDB 缓冲池启动时加载

  • InnoDB 全文分析器插件

  • 多源复制

  • 在线缓冲池大小调整

  • 密码验证插件

  • 查询重写插件

  • 复制筛选

  • CREATE TABLESPACE SQL 语句