本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# Aurora MySQL 数据库引擎更新 2021-05-25（版本 2.10.0）（已弃用）
**版本：**2.10.0
Aurora MySQL 2.10.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、1.23.\$1、2.04.\$1、2.07.\$1、2.08.\$1、2.09.\$1、2.10.\$1、3.01.\$1 和 3.02.\$1。
您可以将现有的 Aurora MySQL 2.\$1 数据库集群升级到 Aurora MySQL 2.10.0。对于运行 Aurora MySQL 版本 1 的集群，您可以直接将现有 Aurora MySQL 1.23 或更高版本的集群升级到 2.10.0。您也可以将快照从当前支持的任何 Aurora MySQL 版本还原到 Aurora MySQL 2.10.0。
如果您有任何问题或疑问，可通过社区论坛和 [AWS Support](https://aws.amazon.com/support) 联系 AWS Support。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[维护 Amazon Aurora 数据库集群](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html)。
**注意**
有关如何升级 Aurora MySQL 数据库集群的信息，请参阅《Amazon Aurora 用户指南》**中的[升级 Aurora MySQL 数据库集群的次要版本或补丁程序级别](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html)。
## 改进
**修复了下面列出的安全问题和 CVE：**
对托管环境中的处理进行微调的修复和其他增强功能。其他 CVE 修复如下：
+ [CVE-2021-23841](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-23841)
+ [CVE-2021-3449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-3449)
+ [CVE-2020-28196](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28196)
+ [CVE-2020-14790](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14790)
+ [CVE-2020-14776](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14776)
+ [CVE-2020-14567](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14567)
+ [CVE-2020-14559](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14559)
+ [CVE-2020-14553](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14553)
+ [CVE-2020-14547](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14547)
+ [CVE-2020-14540](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14540)
+ [CVE-2020-14539](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14539)
+ [CVE-2018-3251](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3251)
+ [CVE-2018-3156](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3156)
+ [CVE-2018-3143](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3143)
+ [CVE-2016-5440](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5440)
**新功能：**
+ Aurora MySQL 现在支持 `db.t3.large` 实例类。
+ *二进制日志复制：*
+ 引入了二进制日志 I/O 缓存，通过减少写入器线程和转储线程之间的争用来提高二进制日志性能。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[优化二进制日志复制](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html#binlog-optimization)。
+ 在 [Aurora MySQL 版本 2.08](AuroraMySQL.Updates.2080.md) 中，我们引入了二进制日志 (binlog) 处理，以便在涉及非常大的事务时缩短崩溃恢复时间和提交时间延迟。对于启用了 GTID 的集群，现在支持这些改进。
+ *改进了读取器实例的可用性：*
+ 以前，写入器实例重新启动时，Aurora MySQL 集群中的所有读取器实例也会重新启动。从今天起，区域内读取器实例在写入器实例重启期间继续提供读取请求，从而提高了集群中的读取可用性。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[重启 Aurora MySQL 集群（版本 2.10 及更高版本）](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_RebootCluster.html#aurora-mysql-survivable-replicas)。
**重要**
升级到 Aurora MySQL 2.10 之后，重启写入器实例不会重启整个集群。如果您想重启整个集群，现在您可以在重启写入器实例后重启集群中的任何读取器实例。
+ 改进了逻辑提前读取 (LRA) 技术请求的提前读取页面的读取性能。这是通过在发送到 Aurora 存储的单个请求中批处理多个页面读取来完成的。因此，使用 LRA 优化的查询的执行速度提高了 3 倍。
+ *零停机时间重启和修补：*
+ 改进了零停机时间重启 (ZDR) 和零停机时间修补 (ZDP)，以在更广泛的场景中启用 ZDR 和 ZDP，包括增加了对启用二进制日志记录的情况的支持。此外，还提高了对 ZDR 和 ZDP 事件的可见性。有关详细信息，请参阅《Amazon Aurora 用户指南》**中的 [Amazon Aurora MySQL 的零停机重启（ZDR）](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.html#AuroraMySQL.Replication.Availability)和[使用零停机时间修补](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.Patching.html#AuroraMySQL.Updates.ZDP)。
**可用性改进：**
+ 当数据库在先前中断的 DDL 活动期间创建了大量临时索引和表时，改进了启动速度。
+ 修复了在中断的 DDL 操作崩溃恢复期间重复重启的多个相关问题，如 `DROP TRIGGER`、`ALTER TABLE`，特别是修改表中分区类型或分区数的 `ALTER TABLE` 问题。
+ 修复了在数据库活动流 (DAS) 日志处理期间可能导致服务器重启的问题。
+ 修复了处理系统表 `ALTER` 查询时打印错误消息的问题。
**常规改进。**
+ 修复了查询缓存可能会在读取器实例上返回过时结果的问题。
+ 修复了系统变量 `innodb_flush_log_at_trx_commit` 设置为 0 或 2 时某些 Aurora 提交指标未更新的问题。
+ 修复了存储在查询缓存中的查询结果未被多语句事务刷新的问题。
+ 修复了可能导致二进制日志文件上次修改的时间戳无法正确更新的问题。这可能会导致在达到客户配置的保留期之前提前清除二进制日志文件。
+ 修复了崩溃恢复后从 InnoDB 报告错误的二进制日志文件名和位置的问题。
+ 修复了如果 `binlog_checksum` 参数设置为 `NONE`，可能导致大型事务生成不正确的二进制日志事件的问题。
+ 修复了在复制的事务包含 DDL 语句和大量行更改时导致二进制日志副本停止并显示错误消息的问题。
+ 修复了删除表时导致读取器实例重启的问题。
+ 修复了在尝试使用大型事务的二进制日志文件时导致开源连接器失败的问题。
+ 修复了在具有大几何值的表上创建空间索引后，可能导致大几何列查询结果不正确的问题。
+ 现在，数据库在重新启动期间重新创建临时表空间，这允许释放和回收关联的存储空间。
+ 修复了无法在 Aurora 读取器实例上截断 `performance_schema` 表的问题。
+ 修复了导致二进制日志副本停止并出现 `HA_ERR_KEY_NOT_FOUND` 错误的问题。
+ 修复了在运行 `FLUSH TABLES WITH READ LOCK` 语句时导致数据库重新启动的问题。
+ 修复了无法在 Aurora 读取器实例上使用用户级锁定功能的问题。
## 集成了 MySQL 社区版本错误修复
+ 当事务隔离级别设置为 [REPEATABLE READ](https://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-isolation-levels.html#isolevel_repeatable-read) 时，交错事务有时可能会使副本应用程序死锁。（错误 \$125040331）
+ 当存储过程包含引用一个视图的语句，而该语句又引用了另一个视图时，该过程不能多次成功调用。（错误 \$187858、错误 \$126864199）
+ 对于具有多个 `OR` 条件的查询，优化程序现在的内存效率更高，并且超过 [range\$1optimizer\$1max\$1mem\$1size](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_range_optimizer_max_mem_size) 系统变量规定内存限制的可能性更小。此外，该变量的默认值已从 1,536,000 提高到 8,388,608。（错误 \$179450、错误 \$122283790）
+ *复制：*在由副本的 SQL 线程调用以从中继日志中读取下一个事件的 `next_event()` 函数中，SQL 线程在遇到错误 (例如，由于中继日志关闭) 时没有释放获取的 `relaylog.log_lock`，导致等待从中继日志中获取锁定的所有其他线程挂起。采用此修复方式后，锁定在这种情况下将于 SQL 线程离开函数之前释放。（错误 \$121697821）
+ 使用虚拟列修复 `ALTER TABLE` 内存损坏。（错误 \$124961167、错误 \$124960450）
+ *复制：*如果多线程副本需要处理大于该大小的事务，则无法使用 [slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) 来配置较小的队列大小。任何大于 [slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) 的数据包都会被拒绝并显示错误 `ER_MTS_EVENT_BIGGER_PENDING_JOBS_SIZE_MAX`，即使该数据包小于 [slave\$1max\$1allowed\$1packet](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_max_allowed_packet) 设置的限制。采用此修复方式后，[slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) 将成为软限制而不是硬限制。如果数据包的大小超过了 [slave\$1pending\$1jobs\$1size\$1max](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_pending_jobs_size_max) 但小于 [slave\$1max\$1allowed\$1packet](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_max_allowed_packet)，则该事务将保留直到所有副本工作线程都有空队列为止，然后进行处理。所有后续事务将一直保留到大型事务完成。因此，副本工作线程的队列大小可以受到限制，同时仍允许偶尔执行较大事务。（错误 \$121280753、错误 \$177406）
+ *复制：*使用多线程副本时，应用程序错误显示的工作线程 ID 数据与性能架构副本表中外部化的数据不一致。（错误 \$125231367）
+ *复制：*对于在 [-gtid-mode=ON](https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_gtid_mode)、[-log-bin=OFF](https://dev.mysql.com/doc/refman/5.7/en/replication-options-binary-log.html#sysvar_log_bin) 模式下使用 [-slave-skip-errors](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_slave_skip_errors) 运行的基于 GTID 的复制副本，当遇到应忽略的错误时，`Exec_Master_Log_Pos` 不会正确更新，从而导致 `Exec_Master_Log_Pos` 失去与 `Read_master_log_pos` 的同步。如果未指定 `GTID_NEXT`，则从单语句事务回滚时，副本永远不会更新其 GTID 状态。`Exec_Master_Log_Pos` 不会更新，因为即使事务已完成，其 GTID 状态也会显示为其他状态。此修复消除了只在指定 `GTID_NEXT` 的情况下回滚事务时才更新 GTID 状态的限制。（错误 \$122268777）
+ *复制：*禁用二进制日志记录时，部分失败的语句未正确使用自动生成或指定的 GTID。此修复可确保在禁用二进制日志记录时，部分失败的 [DROP TABLE](https://dev.mysql.com/doc/refman/5.7/en/drop-table.html)、部分失败的 [DROP USER](https://dev.mysql.com/doc/refman/5.7/en/drop-user.html) 或部分失败的 [DROP VIEW](https://dev.mysql.com/doc/refman/5.7/en/drop-view.html) 会分别使用相关的 GTID 并将其保存到 `@@GLOBAL.GTID_EXECUTED` 和 `mysql.gtid_executed` 表中。（错误 \$121686749）
+ *复制：*由于检索不属于 MySQL 5.5 的 [server\$1uuid](https://dev.mysql.com/doc/refman/5.7/en/replication-options.html#sysvar_server_uuid) 时出错，运行 MySQL 5.7 的副本无法连接到 MySQL 5.5 源。这是由于检索 `server_uuid` 的方法更改造成的。（错误 \$122748612）
+ *复制*：以无提示方式跳过先前执行的 GTID 事务的 GTID 事务跳过机制对 XA 事务无效。（错误 \$125041920）
+ 因给出了错误的事务 ID 而失败的 [">XA ROLLBACK](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 语句可以用正确的事务 ID 记录在二进制日志中，因此可以由复制副本执行操作。现在，在进行二进制日志记录之前会检查错误情况，不会记录失败的 XA `ROLLBACK` 语句。（错误 \$126618925）
+ *复制：*如果副本是使用未指定源日志文件名和源日志位置的 [CHANGE MASTER TO](https://dev.mysql.com/doc/refman/5.7/en/change-master-to.html) 语句设置的，则在发出 [START SLAVE](https://dev.mysql.com/doc/refman/5.7/en/start-slave.html) 之前关闭，然后通过设置为选项 [-relay-log-recovery](https://dev.mysql.com/doc/refman/5.7/en/replication-options-replica.html#sysvar_relay_log_recovery)) 重新启动，复制没有启动。发生这种情况的原因是，在尝试恢复中继日志之前没有启动接收方线程，因此中继日志中没有可用的日志轮换事件来提供源日志文件名和源日志位置。在这种情况下，现在副本跳过中继日志恢复并记录警告，然后继续开始复制。（错误 \$128996606、错误 \$193397）
+ *复制：*在基于行的复制中，从含有 `utf8mb3` 列的表复制到使用 `utf8mb4` 字符集定义该列的具有相同定义的表时，会返回错误显示字段长度的消息。（错误 \$125135304、错误 \$183918）
+ *复制：*当在使用 GTID 的复制副本上发出 [RESET SLAVE](https://dev.mysql.com/doc/refman/5.7/en/reset-slave.html) 语句时，现有的中继日志文件将被清除，但是在清除该通道收到的 GTID 集之前，生成了替换的新中继日志文件。因此，以前的 GTID 集作为 `PREVIOUS_GTIDS` 事件写入新的中继日志文件，导致复制过程中出现致命错误，指出副本的 GTID 比源多，即使两个服务器的 gtid\$1executed 集都是空的。现在，当 `RESET SLAVE` 发出时，收到的 GTID 集将在生成新的中继日志文件之前清除，就不会发生这种情况了。（错误 \$127411175）
+ *复制：*当 GTID 用于复制时，那些包括导致解析错误 ([ER\$1PARSE\$1ERROR](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html#error_er_parse_error)) 语句的事务，无法通过注入具有相同 GTID 的空事务或替换事务的推荐方法手动跳过。此操作应导致副本将 GTID 识别为已使用，从而跳过共享其 GTID 的不需要的事务。但是，尽管无论如何都要跳过事务，在解析错误的情况下，由于语句在检查 GTID 以查看是否需要跳过之前解析了语句，因此复制应用程序线程由于解析错误而停止。采用此修复方式后，如果因为已经使用了 GTID 而需要跳过相关事务，则复制应用程序线程现在会忽略解析错误。请注意，此行为更改不适用于由 `mysqlbinlog` 生成的二进制日志输出组成的工作负载。在这种情况下，紧跟着跳过的事务之后出现解析错误的事务也会以无提示的方式跳过，因为该事务应引发错误。（错误 \$127638268）
+ *复制：*启用 SQL 线程以通过 GTID 跳过部分事务。（错误 \$125800025）
+ *复制：*向 `WAIT_UNTIL_SQL_THREAD_AFTER_GTIDS()` 提供负数或小数超时参数时，服务器出现意外行为。采用此修复方式：
+ 小数超时值按原样读取，没有舍入。
+ 如果服务器处于严格 SQL 模式，则拒绝负超时值并显示错误；如果服务器不处于严格 SQL 模式，则该值会使函数立即返回 `NULL` 而无需等待，然后发出警告。（错误 \$124976304、错误 \$183537）
+ *复制*：如果 `WAIT_FOR_EXECUTED_GTID_SET()` 函数与包括小数部分 (例如 1.5) 的超时值一起使用，则转换逻辑中的错误意味着超时向下舍入到最接近的整秒，对于小于 1 秒的值 (例如，0.1)，则为零。转换逻辑现已被纠正，以便按照最初指定的方式应用超时值，而不舍入。感谢 Dirkjan Bussink 的贡献。（错误 \$129324564、错误 \$194247）
+ 启用 GTID 后，多语句事务中断开的 XA 事务上的 [XA COMMIT](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 会引发断言。（错误 \$122173903）
+ *复制：*如果手动设置 [gtid\$1next](https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_gtid_next) 值时为未知的事务标识符发出 [XA ROLLBACK](https://dev.mysql.com/doc/refman/5.7/en/xa.html) 语句，则在调试版本中引发了断言。如果 XA `ROLLBACK` 语句失败并出现错误，现在服务器不会尝试更新 GTID 状态。（错误 \$127928837、错误 \$190640）
+ 修复 `CASE` 子句中使用多个 `ORDER BY` 函数时排序顺序错误的问题（错误 \$122810883）。
+ 某些使用排序的查询可能会在优化期间访问未初始化的列并导致服务器退出。（错误 \$127389294）
## 与 Aurora MySQL 版本 1 进行比较
以下 Amazon Aurora MySQL 功能在 Aurora MySQL 版本 1（兼容 MySQL 5.6）中受支持，但这些功能目前在 Aurora MySQL 版本 2（兼容 MySQL 5.7）中不受支持。
+ 哈希联接。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[使用哈希联接优化大型 Aurora MySQL 联接查询](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.BestPractices.html#Aurora.BestPractices.HashJoin)。
+ 用于异步调用 AWS Lambda 函数的本机函数。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[使用 Aurora MySQL 本机函数调用 Lambda 函数](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Integrating.Lambda.html#AuroraMySQL.Integrating.NativeLambda)。
+ 扫描批处理。有关更多信息，请参阅“[Aurora MySQL 数据库引擎更新 2017-12-11（版本 1.16）（已弃用）](AuroraMySQL.Updates.20171211.md)”。
+ 使用 Amazon S3 存储桶从 MySQL 中迁移数据。有关更多信息，请参阅《Amazon Aurora 用户指南》**中的[使用 Amazon S3 存储桶从 MySQL 迁移数据](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Migrating.ExtMySQL.html#AuroraMySQL.Migrating.ExtMySQL.S3)。
## 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 语句