Amazon Aurora MySQL 3.04 升级指南 解锁 r8g（Graviton4）的爆炸性能
内容提要
Aurora MySQL 3.04将于2026年10月终止支持，建议升级至3.10 LTS版本，该版本支持r8g实例，性能提升约2倍。文章详述了升级前的预检查、零停机补丁、蓝绿部署及回滚方案，强调需排查新增关键字、比对参数差异，并建议将实例类型变更与版本升级同步进行。
延伸解读
升级路径选择：LTS 与强制升级的差异
3.04 终止支持后，未主动升级的集群会在维护窗口被强制升级到当时的 preferred 版本，该版本不保证是 LTS。若业务需要长期驻留 LTS，应主动升级到 3.10，而非依赖自动升级。同时，已弃用的 3.05–3.07 版本需优先处理，避免落入非受支持状态。
性能提升的关键：版本与实例代际叠加
实测显示，仅升级版本时，只读负载提升 8%–19%，但写入负载在高并发下因实例饱和无提升甚至略降。而升级到 3.10 并搭配 r8g（Graviton4）后，读写混合吞吐约提升 2 倍，只读约 2.7 倍，延迟降低约一半。因此，若实例已接近 CPU 上限，应同步升级实例类型，蓝绿部署可一次完成两项变更。
升级前必查：新关键字与参数默认值差异
3.06 引入的五个新关键字（如 accept、content_type）在 3.10.5 实测为非保留字，但保留状态随版本变化，建议在目标版本上查询 information_schema.KEYWORDS 确认，并为相关标识符加反引号。此外，参数默认值变化（如 innodb_undo_log_truncate 从 OFF 变 ON）可能影响行为，需比对 3.04 与 3.10 的默认值。
回滚并非简单切换：蓝绿部署的增量数据追回
蓝绿部署的 -old 集群并非零成本回滚保障：切换后新集群的增量数据不会同步回 -old，需先确定切换时刻的 binlog 位点，再建立复制补齐增量，且需停写窗口。升级前务必手动创建快照，并规划好增量补齐方案，避免回滚时手忙脚乱。
Q&A
Aurora MySQL 3.04 何时终止标准支持？如果继续使用 LTS 版本，应升级到哪个版本？
Aurora MySQL 3.04 将于 2026 年 10 月 31 日终止标准支持。如果希望继续使用 LTS 版本，应主动升级到 3.10 LTS 版本。
从 Aurora MySQL 3.04 升级到 3.10 属于什么类型的升级？相比大版本升级有何优势？
从 3.04 升级到 3.10 属于 Aurora MySQL version 3 内部的小版本升级（minor version upgrade）。相比大版本升级，其操作复杂度、故障风险及服务中断时长均显著降低，升级过程更为平稳。
Aurora MySQL 3.10 相比 3.04 在实例支持上有哪些主要变化？
3.10 支持 db.r7i 和 db.r8g 实例类，其中 r8g 基于 Graviton4，性能大幅提升。此外，集群最大存储容量从 128 TiB 提升到 256 TiB。
升级到 Aurora MySQL 3.10 时，需要重点排查哪些新增关键字？如何排查？
需要重点排查 3.06.0 引入的五个新关键字：accept、aws_bedrock_invoke_model、aws_sagemaker_invoke_endpoint、content_type、timeout_ms。可以通过查询 information_schema.COLUMNS、TABLES 和 ROUTINES 来检查对象定义中是否使用了这些关键字。
Aurora MySQL 升级时，零停机补丁（ZDP）在什么情况下可能无法生效？
ZDP 可能无法生效的情况包括：存在长时间运行的查询或事务、使用临时表、用户锁或表锁（如 DDL 执行期间）、存在待应用的参数变更。此时升级会退回标准重启行为，导致连接中断。
就地升级和蓝绿部署在回滚能力上有何区别？
就地升级只能从升级前的快照恢复，会丢失升级后的数据；蓝绿部署保留 -old 集群，但切换后的增量数据需要根据 binlog 位点追回，且 -old 集群在切换后仍计费。
在性能测试中，仅升级版本（3.04 到 3.10）对读写性能有何影响？
仅升级版本时，只读负载在全部并发区间提升 8%–19%；含写入的负载在低并发（8-32）提升 2%–20%，但在高并发（实例饱和）区间没有提升甚至略低 3%–8%。
为什么建议将实例类型变更与版本升级同步进行？
因为 r8g 实例仅在 3.08 及以上版本支持，且实测显示 3.10.5 + r8g 相比 3.04.6 + r6g 在读写混合场景吞吐提升约 2 倍，只读场景约 2.7 倍，延迟降低一半。同步进行可以一次完成两项变更，获得最大性能收益。
