Amazon Aurora MySQL 3.04 升级指南 解锁 r8g（Graviton4）的爆炸性能

摘要：Aurora MySQL 3.04 将于 2026 年 10 月 31 日终止标准支持。本文说明如何选择升级目标版本、为何要继续留在 LTS 就应升级到 3.10，并给出预检查、零停机补丁、蓝绿部署与回滚的实践要点，附参数默认值差异与实测性能对比。

一、前言

Amazon Aurora MySQL 是亚马逊云科技提供的与 MySQL 兼容的关系型数据库引擎，在提供商业数据库的性能和可用性的同时，保持开源数据库的成本和简易性。Aurora 会定期发布新的小版本，其中一部分被指定为长期支持（LTS）版本，供那些升级窗口紧张、测试周期长的业务长期驻留。

Aurora MySQL 3.04 是 Aurora 3.x 的第一个长期支持（LTS）版本，发布于 2023 年 7 月，将会在 2026-10-31 终止标准支持（EOL），3.04 标准支持终止后仍未主动升级的集群，会在维护窗口内被强制升级到当时的 preferred（默认）版本。preferred 版本由 Aurora 指定并随时间变化，不保证是 LTS 版本。因此，如需继续使用 LTS 版本，应主动发起升级。

本文讨论从 Aurora MySQL 3.04（以及 3.05–3.09 等其他小版本）升级到 3.10（LTS） 的实践，涵盖版本生命周期、版本差异、升级与回滚方案、常见问题、实测性能对比，以及如何用 AI 工具简化批量升级，帮助您平稳完成升级。

二、版本生命周期

2.1 Aurora MySQL 的版本号与升级性质

Aurora MySQL 的引擎版本格式为 .mysql_aurora...，例如 8.0.mysql_aurora.3.04.3。其中 Aurora 大版本 3 代表与 MySQL 8.0 兼容，04 是 3.x 系列内的功能发布（小版本），最后一位是补丁级别。从 8.4 开始简化了版本号格式，直接使用 8.4.mysql_aurora.8.4.7 这样的形式，Aurora 版本号与 MySQL 兼容版本一致。

因此，从 3.04 升级到 3.10 属于 Aurora MySQL version 3 内部的小版本升级（minor version upgrade）, 相较于大版本升级，其在操作复杂度、故障风险及服务中断时长方面均显著降低，升级过程更为平稳。

2.2 LTS 版本策略

根据官方文档，Aurora MySQL 的 LTS 策略有几个要点直接影响升级规划：

• 使用 LTS 版本的集群通常可以停留在同一个版本上至少三年，或者直到该大版本的标准支持终止，以较早者为准。
• 对于某些关键修复，亚马逊云科技可能在集群维护窗口内自动执行到同一 LTS 内某个补丁级别的托管升级。
• LTS 版本生命周期内发布的补丁级别只包含重要问题的修复，不包含新功能。
• 当前的 Aurora 3 LTS 版本是 3.10.* 和 3.04.*。

2.3 version 3 各小版本与 MySQL 兼容版本对照

三、主要版本差异

从 3.04 到 3.10，变化来自两个层面：Aurora 自身的功能增强，以及底层社区 MySQL 从 8.0.28 到 8.0.42 的累积变更。下面按类别整理 Aurora 侧的主要变化。

1. 实例与容量

• 支持 db.r7i、db.r8g 实例类。r8g 基于 Graviton4，在本文第七节的实测中，同为 4 个 vCPU 的规格下，3.10.5 + r8g 相比 3.04.6 + r6g 在读写混合场景达到约 2 倍吞吐。这两类实例在 3.04 上不可用，是升级后可以立即获得的收益。
• 集群最大存储容量从 128 TiB 提升到 256 TiB。

2. 集成能力

• 支持 zero-ETL 集成，可将 Aurora MySQL 的数据近实时同步到 Amazon Redshift 做分析，无需自建 ETL 管道。
• Amazon Aurora 机器学习支持 Amazon Bedrock（3.06 引入），可以用 SQL 直接从 Aurora MySQL 集群调用 Bedrock 中的模型。
• 支持将数据从 Aurora MySQL 集群导出到 Amazon S3 时使用 KMS 密钥加密（SSE-KMS）的文本文件。

3. 复制与二进制日志

• 内存中继日志缓存。该功能在 3.05 首次引入，可将二进制日志复制吞吐量提升多达 40%。3.10 进一步扩展了适用范围：默认对单线程 binlog 复制、启用 GTID 自动定位的多线程复制生效，从 3.10 起还覆盖了设置 replica_preserve_commit_order = ON 的多线程复制（即使未启用 GTID）。3.10 中可通过新参数 aurora_in_memory_relaylog 控制。
• 二级索引并行应用。为含多个二级索引的大表复制事务时，binlog 副本引入线程池并行应用二级索引变更，由集群参数 aurora_binlog_replication_sec_index_parallel_workers 控制。
• 新增存储过程 mysql.rds_set_binlog_source_ssl，可为 binlog 副本设置 SOURCE_SSL 以启用加密复制。

4. 全球数据库

• 辅助读取器实例现在可以在计划外事件（硬件故障、网络中断）期间完成启动并处理读请求。此前在这类事件中，辅助读取器实例无法重启。
• 跨区域切换（switchover）期间的写入器停机时间缩短到通常不足一分钟，降低计划内区域切换的影响。

5. 运维与可观测性

• 新增存储过程 mysql.rds_set_read_only，可修改集群中数据库实例上 read_only 全局系统变量的值。
• 新增全局状态变量 aurora_tmz_version，表示引擎当前使用的时区（TZ）信息版本，取值遵循 IANA 时区数据库版本格式（如 2023c）。跨版本升级后如果对时区敏感，可以用它确认时区数据版本。
• 新增 aurora_temptable_ram_allocation 和 aurora_temptable_max_ram_allocation 两个全局状态变量，显示内部临时表占用的内存量，便于诊断临时表内存问题。
• 新增系统变量 aurora_optimizer_trace_print_before_purge，可在服务器从内存清除跟踪记录前，把优化器跟踪打印到错误日志。
• 支持自动 undo 表空间截断（3.06 引入），清除 undo 日志后可回收 undo 表空间中未使用的空间。对于长期运行、undo 空间增长明显的集群，这是一项实际的运维改善。

6. 需要重点关注的兼容性变更

可以用下面的语句做一次快速排查：

-- 检查列名
SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME
FROM information_schema.COLUMNS
WHERE COLUMN_NAME IN ('accept','content_type','timeout_ms',
                      'aws_bedrock_invoke_model','aws_sagemaker_invoke_endpoint')
  AND TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys');

-- 检查表名
SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.TABLES
WHERE TABLE_NAME IN ('accept','content_type','timeout_ms')
  AND TABLE_SCHEMA NOT IN ('mysql','information_schema','performance_schema','sys');

-- 检查存储过程/函数体中的引用（需人工复核结果）
SELECT ROUTINE_SCHEMA, ROUTINE_NAME, ROUTINE_TYPE
FROM information_schema.ROUTINES
WHERE ROUTINE_DEFINITION REGEXP '(^|[^a-zA-Z0-9_])(accept|content_type|timeout_ms)([^a-zA-Z0-9_]|$)'
  AND ROUTINE_SCHEMA NOT IN ('mysql','sys');

如果确实用到了，处理方式是在 SQL 中用反引号包裹标识符（例如 `accept`），或者改名。注意应用代码里拼接的 SQL 同样需要处理。

7. 参数默认值变化

参数默认值变化是版本升级后出现行为变化的常见来源：复制是否批量应用、undo 是否自动截断、内存如何分配，都可能因为一个默认值的翻转而改变。这类差异不会出现在发布说明的功能列表里，只能靠比对得到，所以我们对 3.04 与 3.10 的默认值做了一次实际比对。

四、升级方案

4.1 预检查机制

启动小版本升级时，Aurora 会自动运行预检查，且强制执行、无法跳过。该机制有以下关键特性：

• 预检查在数据库实例停止之前运行，因此本身不产生停机。
• 如果发现不兼容项，Aurora 会在实例停止前自动取消升级，并生成对应事件。
• 详细信息记录在日志文件 PrePatchCompatibility.log 中，大多数条目会附上 MySQL 官方文档中对应的修复说明链接。
• 预检查需要分析数据库中的对象，因此会消耗资源并延长升级总时长。对象数量极多（例如几十万张表）的集群，要为这一步预留时间。

建议在正式升级前，先在测试环境或克隆集群上触发一次升级，完整阅读 PrePatchCompatibility.log，提前处理不兼容项。使用 Aurora 克隆功能创建测试集群的成本较低，且不影响生产环境。

4.2 方案对比：就地升级 vs 蓝绿部署

4.3 零停机补丁（ZDP）

就地升级的停机时间主要取决于 ZDP 是否成功。ZDP 以尽力而为的方式在升级过程中保留客户端连接，成功时应用会话被保留，引擎在升级过程中重启，吞吐量通常出现数秒钟的下降。

ZDP 不适用于操作系统补丁与升级、以及大版本升级；但对所有受支持的 Aurora MySQL 版本和实例类都可用，因此适用于本文讨论的 3.04 → 3.10 场景。此外还有两个实用特性：启用 binlog 复制时，ZDP 会自动断开到 binlog 目标的连接并在重启后自动重连、恢复复制；为写入器打补丁会同时为读取器打补丁，完成后 Aurora 会恢复写入器和读取器上的连接。

以下条件可能导致 ZDP 无法成功完成，此时升级会退回标准行为（即断开连接）：

• 正在执行长时间运行的查询或事务。如果此时仍能执行 ZDP，打开的事务会被取消，但连接会保留。
• 正在使用临时表、用户锁或表锁，例如 DDL 语句执行期间。这类连接会被断开。
• 存在待应用的参数变更（pending parameter changes）。

因此升级前应当：把升级安排在低流量时段（可用 Performance Insights 定位）、暂停批处理与 DDL 作业、确认参数组处于 in-sync 状态。

升级完成后，可以在控制台的事件页面看到 ZDP 的执行结果，包括耗时、以及保留了多少连接、断开了多少连接。数据库错误日志中有更详细的过程信息，这是判断影响范围的直接依据。

4.4 用客户端驱动进一步缩短蓝绿切换的中断

无论就地升级还是蓝绿切换，业务感知到的中断时间往往不等于数据库侧的切换时间，而是被客户端放大的：DNS 记录已经指向新节点，但连接池里的物理连接不会因此重连，要等到被回收才会轮换。这一段放大只能在客户端侧解决。

Amazon Web Services Advanced JDBC Wrapper 就是为这类问题设计的。它不是一个独立的数据库驱动，而是包在现有 JDBC 驱动（MySQL Connector/J、PostgreSQL JDBC 等）之外的一层封装，应用需要引入该依赖。常用插件包括快速故障转移（failover2）、增强故障检测（efm2）、读写分离，以及 IAM 身份验证与 Secrets Manager 凭证集成。它的核心机制是在驱动内维护一份实时的集群拓扑缓存，绕开 DNS 解析延迟，从而把连接恢复时间压缩到秒级。详情可以参考这篇博客。

针对蓝绿部署，该驱动提供了专门的 bg 插件（加入 wrapperPlugins 即可启用）。官方文档描述了它在切换过程中做的几件事：

• 持续监控蓝绿部署状态，在切换开始前就把蓝、绿两侧的集群与实例端点及其 IP 地址清单收集齐。
• 在切换进行期间暂停对蓝色环境的 JDBC 调用。这一步不只是保护客户端——它同时给蓝色环境卸载了压力，降低绿色环境的事务延迟，因此能让切换本身更快完成。
• 建立新的蓝色连接时用 IP 地址替换主机名，直接消除过期 DNS 的影响；切换后持续观察 DNS 记录，确认蓝色端点已重新指向后停止替换。
• 切换完成但绿色端点的 DNS 记录仍短暂存在时，主动拒绝到绿色节点的新连接请求；同时能识别切换失败并回滚的情况。

4.5 批量升级的组织方式

实际场景中需要升级的通常不是一个集群，而是数十个。此时需要的不是更快的单次操作，而是可重复执行、可中断续跑、带检查点的流程。建议按以下顺序组织：

1. 盘点：列出账号内所有 Aurora MySQL 集群的当前版本、实例类型、是否开启自动小版本升级、参数组是否为自定义。
2. 分批：按业务重要性和版本分组，非生产环境先行；同一批内的集群串行而非并行切换，避免故障同时爆发。
3. 预演：对每个生产集群创建克隆，在克隆上执行一次升级，收集 PrePatchCompatibility.log。
4. 执行：在低流量窗口执行，每个集群完成后立即做健康检查。
5. 验证：确认版本、连接数、复制状态、关键业务 SQL 的执行计划与响应时间。

盘点可以从以下命令开始：

aws rds describe-db-clusters \
  --query "DBClusters[?Engine=='aurora-mysql'].[DBClusterIdentifier,EngineVersion,Status,DBClusterParameterGroup]" \
  --output table

# 检查自动小版本升级设置（实例级）
aws rds describe-db-instances \
  --query "DBInstances[?Engine=='aurora-mysql'].[DBInstanceIdentifier,DBInstanceClass,AutoMinorVersionUpgrade]" \
  --output table

第八节介绍如何用 AI 工具把这套流程从编写脚本转为描述意图。

五、回滚方案

回滚是升级方案里容易被低估的部分，引擎版本一旦升上去就无法直接修改回来，唯一的退路是回到升级前的数据副本，所以退路必须在升级之前准备好。

几点实践建议：

• 升级前一定手动创建一个快照，不要只依赖自动备份。手动快照不受备份保留期限制。
• 蓝绿部署的 -old 集群并非零成本的回滚保障：它在切换后仍然计费，且只保留到您删除蓝绿部署为止。删除前请确认所有业务流量均已切换到新集群。
• 使用 -old 集群回滚并非仅切换端点。切换完成后复制关系随即断开，新集群上产生的写入不会同步回 -old。回滚需要先确定切换时刻新集群的 binlog 位点，再将该位点之后的增量变更补齐到 -old（建立从新集群到 -old 的 binlog 复制），确认数据一致后再将应用切回旧端点。该过程需要停写窗口，请在升级前准备好增量补齐方案与位点记录方式，不要在需要回滚时才开始设计。
• 如果业务对数据零丢失有硬要求，保留 -old 集群的同时注意设置新集群的 binlog 保存周期。

六、常见问题

1. 新增关键字会不会影响现有对象定义

原因

3.06.0 为支持 Amazon Bedrock 集成引入了 accept、aws_bedrock_invoke_model、aws_sagemaker_invoke_endpoint、content_type、timeout_ms 五个新关键字，官方发布说明建议升级前检查对象定义并为这些标识符加引号。

潜在影响

按我们在 3.10.5 上的实测，这五个词在 information_schema.KEYWORDS 中的 RESERVED 均为 0，属于非保留关键字，用作表名与列名（含视图、存储过程定义中的引用）不加反引号也能正常解析，因此这一项在 3.10.5 上的实际影响比预期小。

解决方案

• 在自己的目标版本上执行一次 information_schema.KEYWORDS 查询，确认这些词的保留状态，用确定结果代替推断。
• 用第三节给出的 information_schema 查询做一次全量排查，确认哪些对象使用了这些标识符。即使当前版本不会报错，这份清单在后续升级到更高版本时仍然适用。
• 按官方建议在 DDL 与应用 SQL 中用反引号包裹这些标识符，或对其重命名。该改动成本较低，可一次性消除后续版本的不确定性。
• 不要只查生产库——测试库、历史归档库中的对象同样会参与升级前检查。

2. ZDP 未能保留连接，业务出现连接中断

原因

升级时集群上存在长事务、临时表、用户锁或表锁，或者参数组存在待应用的变更，导致 ZDP 找不到合适的执行窗口，退回标准重启行为。

潜在影响

所有连接被断开，中断时间通常为数分钟，期间业务持续报错；如果应用没有重试机制，会产生业务失败而不仅是延迟。

解决方案

• 升级前用 information_schema.INNODB_TRX 与 SHOW PROCESSLIST 确认没有长事务，暂停批处理与 DDL 作业。
• 确认参数组状态为 in-sync（describe-db-clusters 的 DBClusterParameterGroupStatus），有待重启生效的参数变更时先完成重启。
• 选择低流量窗口，并确保应用侧实现了带指数退避与抖动的重试。
• 升级后到事件页面核对实际保留/断开的连接数，作为下一批集群的经验输入。

3. 切换或重启后，业务流量没有完全转移到新写入器

原因

客户端侧的 DNS 缓存与连接池行为。JVM 默认的 DNS 缓存策略会缓存解析结果（OpenJDK 下正向解析默认缓存 30 秒），而连接池中已建立的物理连接不会因为 DNS 记录变化而重连——它们会一直用到被回收。以 HikariCP 的默认配置为例，maxLifetime 为 30 分钟，且当 minimumIdle 等于 maximumPoolSize 时 idleTimeout 实际不生效，因此连接的轮换周期可能长达 30 分钟。

潜在影响

切换完成后，部分连接仍然指向旧的写入器，导致报错或写入落到非预期的实例上。这类问题的表现往往是”切换早就完成了，但业务错误还在持续”。

解决方案

• 把 JVM 的 DNS TTL 调低：-Dnetworkaddress.cache.ttl=5，与 RDS DNS 区域自身 5 秒的 TTL 对齐。
• 缩短连接池的 maxLifetime，并配置合理的连接有效性检测。
• 使用 Amazon Web Services Advanced JDBC Wrapper 的 failover2、efm2 插件，让客户端主动感知拓扑变化，而不是被动等超时。
• 对于蓝绿部署，建议在切换后检查并确认所有流量都已落到新集群。

七、性能对比

性能变化是版本升级必须评估的维度。为了把「版本带来的变化」和「实例代际带来的变化」分开看，我们把测试设计成两步：先在同一种实例类型上只改变引擎版本，再把 3.10 之后才可用的 r8g 加进来作为第三条对比线。

测试方法

第一步：只升级版本，实例类型不变

先看同为 db.r6g.xlarge 时 3.04.6 与 3.10.5 的差异。三种负载的 QPS 实测值如下（括号内为 3.10.5 相对 3.04.6 的变化）：

三种负载分成两类：

• 只读负载在全部并发区间都有提升，幅度 8%–19%，其中 8 线程时从 13,274 提升到 15,797 QPS。这是本次升级中较为稳定的一项收益。
• 含写入的负载，收益集中在低并发。oltp_write_only 在 8 线程时提升 20%（5,162 → 6,176 QPS），到 32 线程收窄到 2%，128 线程之后转为 -3% 左右。oltp_read_write 的走势相同，256 线程时为 -8%。

含写入的负载在高并发下略低的原因可以从绝对值看出：oltp_read_write 在 3.04.6 上于 64 线程达到 23,403 QPS 后不再增长，3.10.5 也稳定在 22,314–23,335 区间。db.r6g.xlarge 仅有 4 个 vCPU，32–64 线程已经达到实例的处理上限，此后两个版本受同一 CPU 资源约束，差异处于测试波动范围内。该区间的数据并不表示新版本性能下降，而是表明在资源饱和区间，升级版本无法带来吞吐提升，需要同时增加计算资源。

[图 1：oltp_read_only（左）与 oltp_write_only（右）的 QPS。灰色虚线为 3.04.6/r6g，橙色为 3.10.5/r6g，两者之差即版本收益]

第二步：加入 r8g 机型

Aurora MySQL 从 3.08.0 及以上版本开始支持 db.r8g（Graviton4）实例族。接下来我们把 db.r8g.xlarge（同样 4 vCPU）作为第三条线加进来，与 3.04.6/r6g 的 QPS 实测值对比如下（括号内为相对 3.04.6/r6g 的倍数）：

同样是 4 个 vCPU 的规格，三种负载的吞吐上限都被提高了一倍以上，r8g 的饱和点比 r6g 更靠后。r6g 在 32–64 线程趋于平稳，r8g 则持续增长至 64 线程，且趋于平稳后的吞吐水平高出一倍以上。这表明在相同 vCPU 数量下，Graviton4 的单核性能与并发扩展能力均更优，两者共同构成了上述倍数。

[图 2：oltp_read_write 的 QPS。橙色与灰色虚线之间是版本收益，蓝色与灰色虚线之间是版本叠加实例代际的收益]

延迟

读写混合场景的平均延迟与 p95 延迟（毫秒，越低越好）：

延迟的走势与吞吐一致：只升级版本时，8–32 线程的延迟有小幅改善（8 线程平均延迟从 18.32 毫秒降到 16.47 毫秒），64 线程之后两个版本基本重合、高并发下 3.10.5 略高——这仍然是饱和区间排队的结果。换到 r8g 之后，各并发点的平均延迟都降到原来的一半左右，p95 的改善幅度相当。对延迟敏感的业务，实例代际的影响比引擎版本更值得关注。

[图 3：oltp_read_write 的平均延迟（左）与 p95 延迟（右），纵轴越低越好]

tpcc-mysql

换一种更接近交易型业务的负载做交叉验证，100 warehouses 下的 TpmC：

结论与 sysbench 一致：只升级版本时，8–32 连接提升 9%–14%，64 连接之后两个版本趋于平稳并略有下降；换到 r8g 之后，8–16 连接为 1.42–1.63 倍，32 连接以上达到 1.93–2.05 倍。两种工具、两种数据集呈现同一规律，表明这一结果不局限于某个特定负载。

[图 4：tpcc-mysql 的 TpmC（100 warehouses）]

性能小结

• 只升级版本时，读取场景是稳定收益，写入场景的收益取决于并发区间。只读负载在全部并发区间提升 8%–19%；含写入的负载在低并发（8–32）提升 2%–20%，在实例已经饱和的高并发区间没有提升甚至略低 3%–8%。
• 在资源饱和区间，升级版本不会带来吞吐提升。如果实例在升级前已长期运行在 CPU 上限附近，仅升级版本的收益有限，需要同时考虑增加计算资源。
• 版本与实例代际叠加才是收益的主要来源。同样 4 个 vCPU，3.10.5 + r8g 相比 3.04.6 + r6g 在读写混合场景达到约 2 倍、只读场景达到约 2.7 倍，平均延迟降到一半左右。而 r8g 只有升级到 3.08 以及以上版本之后才开始支持。
• 这也是建议将实例类型变更与版本升级安排在同一个窗口的原因：蓝绿部署在创建绿色环境时就支持指定新的实例类型，两项变更可以一次完成。
• 上面的结论建立在 xlarge 这个规格上。规格越大、vCPU 越多，饱和点越靠后，同一并发数落在曲线上的位置也不同，因此请按自己的实例规格和业务并发做验证。

八、AI 助力升级

升级工作中耗时较多的环节通常不是升级操作本身，而是资源盘点、参数比对、批量脚本编写与结果核对。这些环节适合借助 AI 工具完成。

8.1 Amazon Aurora MySQL power for Kiro

Amazon Aurora MySQL power for Kiro 把 Aurora 的领域知识打包进 Kiro，由三部分组成：

• MCP server——连接实时环境，查询数据库实例状态、读取参数组、代为调用云服务 API。
• Steering files——由领域专家整理的最佳实践，让建议贴合当前的产品标准，而不是通用大模型的泛化回答。
• Validation hooks——在部署前校验配置，提前标出问题。

安装方式是在 Kiro 侧边栏的 Powers 面板中找到 Amazon Aurora MySQL 并安装，或在 powers marketplace 中搜索 Aurora 后添加。使用前需具备管理 Aurora 与 RDS 资源的相应权限。

它生成命令供您审核后再执行，每一步都需要明确确认，不会擅自改动云上资源。对于升级这类操作，这个约束是必要的。

8.2 用自然语言完成升级前的盘点与检查：一组实测记录

下面是我们在准备本文时的真实操作记录。工具是终端里的 Kiro CLI，运行在一台已配置好凭证的 Amazon EC2 实例上，可以直接调用云服务 API 与 mysql 客户端。每一条都是「描述意图 → 它生成命令 → 审核后执行 → 得到结论」，输出为真实结果（集群名已做脱敏处理）。

例一：盘点账号内所有集群，标出需要处理的对象

提问：
列出账号内所有 Aurora MySQL 集群的小版本、是否 LTS、实例类、自动小版本
升级开关和参数组，标出哪些待升级到 3.10、哪些设置不符合 LTS 的建议。

它把 describe-db-clusters 与 describe-db-instances 的结果按集群做了关联（自动小版本升级是实例级设置，集群级接口里没有），并加上了判断逻辑：

集群              小版本   LTS     实例类          AutoMinorVerUpg  待处理
--------------- ------- ------- --------------- ---------------- --------------------------------
cluster-a        3.04.6  LTS     db.r6g.xlarge   False            待升级到 3.10
cluster-b        3.04.6  LTS     db.r7g.large    True             待升级到 3.10; 自动小版本升级开启
cluster-c        3.10.5  LTS     db.r6g.xlarge   False            OK
cluster-d        3.10.5  LTS     db.r8g.xlarge   False            OK
test-304         3.11.1  非 LTS  db.r6g.large    True             自动小版本升级开启
analytics-demo   3.11.1  非 LTS  db.serverless   True             自动小版本升级开启

共 6 个 Aurora MySQL 集群，其中待升级到 3.10 的 2 个

例二：核查新增关键字，并确认其对业务的实际影响

提问：
检查数据库里是否有对象用到了 accept、content_type、timeout_ms 这几个 3.06 引入的关键字；另外确认它们在 3.10 上是否为保留字。

前半个问题它用第三节那组 information_schema 查询解决了，能同时查出表名、列名、视图列和存储过程定义中的引用。后半个问题它给出的方法更有价值——直接查 information_schema.KEYWORDS，这也是官方发布说明所指向的表：

SELECT WORD, RESERVED FROM information_schema.KEYWORDS
WHERE WORD IN ('ACCEPT','CONTENT_TYPE','TIMEOUT_MS',
               'AWS_BEDROCK_INVOKE_MODEL','AWS_SAGEMAKER_INVOKE_ENDPOINT');

实测结论见第三节。要点是：这个方法可以在您自己的目标版本上得到确定答案，而不必依赖任何文档或博客里的静态结论。

几条经验

• 把约束写进提问。比对参数默认值时如果不加上「不要用参数组族级别的默认值」这句约束，它会直接查询族级默认值，而 3.04 与 3.10 同属 aurora-mysql8.0 族，由此得到的是「没有差异」这一错误结论。只描述目标而不给出约束，容易得到看似合理但方法错误的答案。
• 只读核查可以授权执行，写操作必须逐条审核。盘点、比对、扫描这类只读操作即使出错也仅需重新执行；而修改参数组、发起升级、删除蓝绿部署这类操作需要人工确认每一条命令。
• 让它把判断逻辑显式写出来。例一里「哪些待升级」「哪些设置不符合建议」是它生成的判断，写成代码之后可以复核规则本身是否正确，比让它直接给结论可靠。
• 生成的脚本先在测试环境或克隆集群上验证，再用于生产。

8.3 Amazon Q Developer CLI 做批量编排

如果需要处理几十个集群，可以用 Amazon Q Developer CLI 生成一整套自动化脚本，典型的分解方式是：获取待升级集群列表 → 批量创建蓝绿部署 → 批量执行切换 → 切换后批量健康检查。每一步单独成脚本、单独验证，比一个大脚本更可控。执行脚本的机器上需要配置好相应的凭证与权限。

一个实践上的提醒：批量切换完成后的健康检查不要只看集群状态，还要检查旧实例上是否仍有业务连接。如果有，说明存在 DNS 缓存或连接池未轮换的问题，需要业务侧进一步处理，而不是继续推进下一批。

8.4 用官方配置助手检查客户端配置

第四节介绍的 Amazon Web Services Advanced JDBC Wrapper 有几十个插件与参数，插件链的组合顺序、超时取值以及各插件对引擎版本的要求都容易出现配置错误。官方仓库为此提供了一个自包含的配置助手 skill——JDBC-WRAPPER-CONFIGURATION-ASSISTANT.md。它是单个 Markdown 文件，包含全部插件、参数、默认值与兼容性约束，放进 Kiro 的 .kiro/skills/ 目录（或其他 AI 工具的知识库）之后，就可以用自然语言让 AI 帮您生成、审查或排查 wrapper 配置。

在升级场景里，它适合用来回答这几类问题：当前的插件链组合是否合理、bg 插件的引擎版本前提是否满足、切换期间各类超时应该怎么取值、以及升级前后客户端配置需不需要调整。

九、升级建议

1. 先确认升级的性质与路径，并主动发起。3.04 → 3.10 是小版本升级，走的是 LTS 到 LTS 的官方推荐路径；但 EOL 后的强制升级目标是当时的 preferred 版本、不保证是 LTS，如需留在 LTS 上，不能依赖自动升级。如果集群还在已弃用的 3.05–3.07 上，应优先处理。
2. 用克隆集群做完整预演。在克隆上执行一次升级，完整阅读 PrePatchCompatibility.log，并用真实业务 SQL 验证执行计划与响应时间。这一步的成本远低于生产环境回滚的代价。
3. 把新增关键字排查列为例行项。accept、content_type、timeout_ms 出现在业务表结构中的概率不低。这三个词在 3.10.5 上实测为非保留字、不会导致解析失败，但保留状态随版本变化，因此建议在自己的目标版本上执行一次 information_schema.KEYWORDS 查询，并为这些标识符加上反引号。
4. 将实例类型变更与版本升级合并到同一个窗口。实测显示同为 4 个 vCPU 的规格，3.10.5 + r8g 相比 3.04.6 + r6g 在读写混合场景达到约 2 倍吞吐、只读场景约 2.7 倍，平均延迟降低约一半；而在实例已达到资源上限时，仅升级版本无法带来吞吐提升。蓝绿部署支持在创建绿色环境时指定新的实例类型。
5. 升级后立即关闭自动小版本升级。否则集群可能被自动升级到非 LTS 版本，失去长期驻留的收益。同时安排每年一次升级到 LTS 最新补丁的计划。
6. 切换前停止应用，切换后重新建立连接。不应依赖 DNS 缓存与连接池自然轮换。同时调低 JVM 的 networkaddress.cache.ttl，并为应用配置带退避的重试机制。
7. 保留退路。升级前手动创建快照；使用蓝绿部署时，在确认所有流量都已落到新集群之后再删除蓝绿部署与旧集群。

十、附录

相关内容推荐

版本与生命周期

• Aurora MySQL 长期支持（LTS）与 beta 版本
• 检查 Aurora MySQL 版本号
• Aurora MySQL version 3 引擎更新说明

升级与回滚

• 升级 Aurora MySQL 集群的小版本或补丁级别
• 使用零停机补丁（ZDP）
• 使用 Amazon Aurora 蓝绿部署进行数据库更新

AI 工具

• Guide your Amazon Aurora MySQL migration with Kiro powers
• Introducing Amazon Aurora powers for Kiro
• Amazon Web Services Advanced JDBC Wrapper

➡️ 下一步行动：

相关产品：

• Amazon Aurora — 适用于 PostgreSQL、MySQL 和 DSQL 的无服务器关系数据库服务
• Amazon RDS — 完全托管的关系数据库服务
• Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
• Amazon Q Developer — 生成式人工智能开发助手
• Amazon EC2 — 安全且可调整大小的计算容量

相关文章：

• 大规模数据库迁移中的 CDC 吞吐优化实践
• Aurora PostgreSQL 大版本升级指南
• 把 RDS MySQL 数据入仓 Amazon Redshift 的三种方式 · 首推 Zero-ETL
• 星合互娱借助 AWS DevOps Agent 构建多游戏智能运维体系
• 使用 Kiro 和 MCP 自动化大规模升级 RDS MySQL 8.0 至 RDS MySQL 8.4

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用