Aurora MySQL 数据库引擎更新 2025-07-31（版本 3.10.0，兼容 MySQL 8.0.42）

版本：3.10 .0

Aurora MySQL 3.10.0 已正式上市。Aurora MySQL 3.10 版本与 MySQL 8.0.42 兼容。有关已发生的社群变更的更多信息，请参阅 MySQL 8.0 Release Notes。

有关 Aurora MySQL 版本 3 中的新功能的详细信息，请参阅与 MySQL 8.0 兼容的 Aurora MySQL 版本 3。有关 Aurora MySQL 版本 3 和 Aurora MySQL 版本 2 之间的区别，请参阅比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3。有关 Aurora MySQL 版本 3 和 MySQL 8.0 社区版的比较，请参阅亚马逊 Aurora 用户指南中的 Aurora MySQL 版本 3 和 MySQL 8.0 社区版的比较。

您可以利用零停机时间修补 (ZDP) 执行就地升级，恢复快照，或者 blue/green 使用亚马逊 RDS Blue/Green 部署启动托管升级，从当前支持的任何 Aurora MySQL 版本 2 集群到 Aurora MySQL 版本 3.10.0 集群。

有关计划升级到 Aurora MySQL 版本 3 的信息，请参阅规划 Aurora MySQL 集群的主要版本升级。有关 Aurora MySQL 升级的一般信息，请参阅《Amazon Aurora 用户指南》中的升级 Amazon Aurora MySQL 数据库集群。

有关疑难解答信息，请参阅 A mazon Aurora 用户指南中的 Aurora MySQL 就地升级疑难解答。

如果您有任何疑问或疑虑，可以在社区论坛和 AWS 支持部门获得AWS 支持。有关更多信息，请参阅亚马逊 Aurora 用户指南中的维护 Aurora 数据库集群。

新特征

• Aurora MySQL 3.10 版扩展了对二进制日志副本的内存中继日志缓存支持。此功能在 3.05 版本中首次引入，可将二进制日志复制吞吐量提高多达 40%。默认情况下，内存中继日志缓存处于启用状态，用于单线程二进制日志复制、启用 GTID 自动定位的多线程复制，从 3.10 版开始，还启用了带有（即使没有）的多线程复制。replica_preserve_commit_order = ON GTIDs您可以在 3.10 中使用新参数控制此功能。aurora_in_memory_relaylog有关更多信息，请参阅 Aurora MySQL 中的二进制日志优化。

• Amazon Aurora 已将其最大存储容量翻了一番，从 128 TiB 增加到 256 TiB，从而在单个数据库集群中实现了更大的工作负载。要在 Aurora MySQL 中使用增加的存储限制，请将集群升级到 3.10 版（与 MySQL 8.0.42 兼容）或更高版本。升级后，Aurora 存储会根据集群卷中的数据量自动扩展至 256 TiB。

改进

安全修复

中等 CVEs：

• CVE-2025-21501

• CVE-2025-21500

• CVE-2025-21543

• CVE-2025-21540

• CVE-2025-21491

• CVE-2025-21490

• CVE-2025-21559

• CVE-2025-21555

• CVE-2025-21497

• CVE-2025-21519

• CVE-2025-21529

• CVE-2025-21505

• CVE-2025-21531

• CVE-2025-21523

• CVE-2025-21503

• CVE-2025-21522

• CVE-2025-21518

• CVE-2025-21577

• CVE-2025-30682

• CVE-2025-30687

• CVE-2025-30688

• CVE-2025-21574

• CVE-2025-21575

• CVE-2025-30693

• CVE-2025-30695

• CVE-2025-30715

• CVE-2025-21584

• CVE-2025-21580

• CVE-2025-21581

• CVE-2025-21585

• CVE-2025-30689

• CVE-2025-21579

• CVE-2025-30696

• CVE-2025-30705

• CVE-2025-30683

• CVE-2025-30684

• CVE-2025-30685

• CVE-2025-30699

• CVE-2025-30704

• CVE-2025-30721

低 CVEs：

• CVE-2025-21520

• CVE-2025-21546

• CVE-2025-30703

• CVE-2025-30681

可用性改进：

• 修复了由于对恢复进度的评估不正确而导致不必要的数据库服务器重新启动的问题。

常规改进：

• 修复了在启用写入转发并修改参数aurora_replica_read_consistency时导致读取器实例不生成错误日志的问题。

• 修复了由于复制线程与访问缓冲区缓存中不存在的表的查询之间的交互而可能导致读取器实例重新启动的问题。

• 修复了数据库实例在零停机时间重启后本地写入转发停止工作的问题。

• 修复了写入转发中的一个问题，即对于包含设置选项的语句，转发的查询可能表现不正确。

• 修复了为撤消表空间插入元数据会触发数据库意外重启的稳定性问题。

• 修复了当表大于 14 TB 时，可能导致数据库集群导出所需的时间比预期长得多的问题。

• 修复了可能导致Innodb_buffer_pool_pages_misc状态变量报告不正确的问题。

• 增加了对在零停机修补 (ZDP) 或零停机时间重启 (ZDR) LAST_INSERT_ID 期间保留的支持。

• Aurora MySQL 使用 8 位值作为虚拟索引 IDs ，以防止 MySQL 撤消格式问题，因为超过此限制可能会导致集群不可用。当接近此限制时，系统现在会将警告消息写入 MySQL 错误日志。如果达到限制，尝试添加新索引将返回错误。有关虚拟索引最佳做法的更多信息，请参阅 Aurora MySQL 文档中的虚拟索引 ID 溢出错误。

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

此版本包括 8.0.42 之前的所有社区错误修复。有关更多信息，请参阅 由 Aurora MySQL 3.x 数据库引擎更新修复的 MySQL 错误。

• 服务器退出可能是由于多个线程同时尝试注册和取消注册元数据 Performance Schema 对象，或者获取和释放元数据锁。（错误 #26502135）