如何在可用维护窗口外升级AWS Aurora MySQL至5.7.x版本

背景信息 #

你当前的Aurora集群版本信息：

MySQL [myapp_db]> SHOW VARIABLES LIKE "%version%";
+-------------------------+------------------------------+
| Variable_name           | Value                        |
+-------------------------+------------------------------+
| aurora_version          | 1.16                         |
| innodb_version          | 1.2.10                       |
| protocol_version        | 10                           |
| slave_type_conversions  |                              |
| version                 | 5.6.10                       |
| version_comment         | MySQL Community Server (GPL) |
| version_compile_machine | x86_64                       |
| version_compile_os      | Linux                        |
+-------------------------+------------------------------+

作为长期运维AWS Aurora的从业者，我可以明确告诉你：不需要被动等默认维护窗口，你可以手动触发升级，甚至自定义升级时间，下面是具体的可行方法和注意事项：

一、手动触发升级（自定义时间/立即执行） #

AWS的维护窗口只是默认的自动升级时间，但你完全可以主动发起升级操作：

• 登录AWS控制台，进入RDS服务，找到你的目标Aurora集群
• 点击集群详情页的「修改」（Modify）按钮
• 在「数据库版本」下拉列表中，选择兼容MySQL 5.7的Aurora版本（注意：Aurora 2.x分支对应MySQL 5.7，你当前的1.16属于Aurora 1.x，跨分支升级是官方支持的）
• 滚动到「维护」配置区域：
  • 若想马上升级，选择「立即应用」（Apply immediately）——重点提醒：这个操作会导致集群重启，有短暂停机，务必在业务低峰期执行
  • 若想指定自己方便的时间，就选择「在维护窗口内应用」，还可以修改维护窗口的时间范围（改成你业务空闲的时间段）
• 确认所有修改内容无误后，提交修改，AWS就会按照你指定的时间执行升级

二、先通过只读副本做升级验证（降低生产风险） #

如果你的业务对可用性要求极高，不想直接动生产集群，可以先在副本上做测试：

• 给当前的Aurora主集群创建一个只读副本实例
• 对这个副本执行上述的版本修改操作，升级到5.7.x版本
• 在副本上运行应用的测试用例，检查SQL语法兼容性、数据完整性、性能表现（比如MySQL 5.7的优化器变化）
• 确认没有问题后，再将生产流量切换到升级后的副本（提升副本为主实例），或者直接升级原主集群

三、关键注意事项 #

• 兼容性检查：MySQL 5.7对比5.6有不少变化，比如ONLY_FULL_GROUP_BY默认开启、SQL_MODE默认更严格、某些函数（如GROUP_CONCAT）的行为改变，一定要先在测试环境验证应用兼容性
• 备份保障：升级前务必手动触发一次集群快照备份，虽然Aurora有自动备份，但手动快照可以确保你有一个升级前的完整数据副本，出问题能快速恢复
• 版本选型：要选择AWS官方支持的Aurora MySQL 5.7版本，避免选到预览版或者已停止维护的版本
• 菜单无5.7选项的情况：如果你的控制台操作菜单里没有显示5.7的版本选项，可能是你的AWS区域还未开放该版本，或者集群使用了老旧的实例类型，这种情况下可以先升级到Aurora 1.x的最新版本，再尝试跨分支升级到5.7

内容的提问来源于stack exchange，提问作者smeeb