Aurora MySQL 数据库引擎更新：2017-08-07（版本 1.14）（已弃用） - Amazon Aurora
零停机时间修补改进MySQL 错误修复汇总
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

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

Aurora MySQL 数据库引擎更新：2017-08-07（版本 1.14）（已弃用）

版本：1.14

Aurora MySQL 1.14 已正式发布。将在 Aurora MySQL 1.14 中创建所有新的数据库集群（包括从快照还原的集群）。Aurora MySQL 1.14 还将对现有 Aurora MySQL 数据库集群进行强制升级。我们将针对早期版本的 Aurora MySQL 的弃用时间表发布单独的公告。

对于 Aurora MySQL 1.14 版，我们将使用集群修补模式，在该模式下，将同时修补 Aurora 数据库集群中的所有节点。更新需要重新启动数据库，因此，将出现 20 到 30 秒的停机，之后，您可以继续使用数据库集群。如果您的数据库集群当前运行的是 1.13 版，Aurora 的零停机时间修补功能可能允许到 Aurora 主实例的客户端连接在升级期间保持活动状态，具体取决于您的工作负载。

如果您有任何疑问或疑虑，可以在社区论坛和 Amazon 支持部门获得Amazon 支持。

零停机时间修补

零停机时间修补 (ZDP) 功能尝试在引擎修补期间尽力保留客户端连接。有关 ZDP 的更多信息，请参阅《Amazon Aurora 用户指南》中的使用零停机时间修补。

改进

  • 修复了当某个记录在辅助索引中发现但未在主索引中发现时出现的不正确的“未发现记录”错误。

  • 修复了可能由在单独的写入跨越 32 页以上时非常强的某个防御性断言 (1.12 中新增) 导致的稳定性问题。此类情况可能在存在诸如较大的 BLOB 值时出现。

  • 修复了因表空间缓存与目录缓存不一致而导致的稳定性问题。

  • 修复了一个问题，即，Aurora 副本在超出连接主实例的最大尝试次数之后变得无响应。如果不活动的时间超出主实例用于运行状况检查的检测信号时长，Aurora 副本现在会重新启动。

  • 修复了一个动态锁，如果一个连接尝试在发出命令 (如 ALTER TABLE) 时获取独占元数据锁 (MDL)，该动态锁可能在非常高的并发度下产生。

  • 修复了在执行逻辑/并行预读时 Aurora 只读副本中发生的稳定性问题。

  • 对 LOAD FROM S3 进行了以下两个方面的改进：

    1. 通过将软件开发工具包重试与现有重试结合使用来更好地处理 Amazon S3 超时错误。

    2. 通过缓存和重复使用客户端状态来优化加载超大型文件或大量文件时的性能。

  • 修复了与针对 ALTER TABLE 运算的快速 DDL 有关的以下稳定性问题：

    1. 当 ALTER TABLE 语句有多个 ADD COLUMN 命令时，列名称不按升序排列。

    2. 要更新的列的名称字符串与该列从内部系统表中提取的对应名称字符串相差一个空终止字符 (/0)。

    3. 正在执行某些 B 树拆分运算。

    4. 当表具有长度可变的主键时的问题。

  • 修复了由于实现 Aurora 副本的全文搜索 (FTS) 索引缓存与主实例的全文搜索索引缓存的一致性耗时过长而导致的副本稳定性问题。当主实例上的大部分新创建的 FTS 索引条目尚未刷新到磁盘中时可能出现这种情况。

  • 修复了索引创建期间可能出现的稳定性问题。

  • 新增了基础设施，用于跟踪每个连接和相关遥测的内存消耗以制定避免内存不足 (OOM) 的策略。

  • 修复了一个问题，即，错误地在 Aurora 副本上允许使用 ANALYZE TABLE。现已阻止该操作。

  • 修复了因逻辑预读和清除之间的争用情况导致的罕见死锁而造成的稳定性问题。

MySQL 错误修复汇总

  • 与派生表 (FROM 子句中的子查询) 相结合的全文搜索导致服务器退出。现在，如果全文操作依赖于派生表，服务器将产生指示无法对具体化表执行全文搜索的错误。(错误 68751、错误 16539903)