AWS RDS Aurora-MySQL实例缩容：是否存在停机情况？

背景说明 #

我们使用Terraform管理AWS资源，近期将跨可用区（AZ）部署的单读写节点AWS RDS Aurora-MySQL8集群，从r5实例缩容至t3实例。现通过AWS控制台的事件日志，分析缩容过程中各DB实例是否存在停机情况。

完整事件日志 #

Cluster
 
April 23, 2025, 16:49 (UTC+01:00)
Completed failover to DB instance: tracker-rds-uat-0
April 23, 2025, 16:49 (UTC+01:00)
Started failover to DB instance: tracker-rds-uat-0
April 23, 2025, 16:43 (UTC+01:00)
Completed failover to DB instance: tracker-rds-uat-1
April 23, 2025, 16:42 (UTC+01:00)
Started cross AZ failover to DB instance: tracker-rds-uat-1
 
 
Writer
 
April 23, 2025, 16:49 (UTC+01:00)
Finished updating DB parameter group
April 23, 2025, 16:49 (UTC+01:00)
DB instance restarted
April 23, 2025, 16:49 (UTC+01:00)
DB instance shutdown
April 23, 2025, 16:48 (UTC+01:00)
Monitoring Interval changed to 0
April 23, 2025, 16:47 (UTC+01:00)
DB instance restarted
April 23, 2025, 16:47 (UTC+01:00)
Finished applying modification to DB instance class
April 23, 2025, 16:42 (UTC+01:00)
DB instance shutdown
April 23, 2025, 16:41 (UTC+01:00)
Applying modification to database instance class
 
 
Reader

April 23, 2025, 16:56 (UTC+01:00)
Finished updating DB parameter group
April 23, 2025, 16:55 (UTC+01:00)
Monitoring Interval changed to 0
April 23, 2025, 16:54 (UTC+01:00)
Finished applying modification to DB instance class
April 23, 2025, 16:54 (UTC+01:00)
DB instance restarted
April 23, 2025, 16:49 (UTC+01:00)
DB instance shutdown
April 23, 2025, 16:49 (UTC+01:00)
DB instance restarted
April 23, 2025, 16:49 (UTC+01:00)
A new writer was promoted. Restarting database as a reader.
April 23, 2025, 16:47 (UTC+01:00)
Applying modification to database instance class
April 23, 2025, 16:42 (UTC+01:00)
DB instance restarted
April 23, 2025, 16:42 (UTC+01:00)
DB instance shutdown

初步解读与疑问 #

16:42时R5 reader实例切换为writer，原R5 writer实例关机；16:47完成当前writer（原reader）的配置变更但未重启；16:49新T3 writer实例启动并触发故障转移，原R5 writer重启为reader（或已变为T3？）；16:49-16:54 reader的状态变化不明。我认为缩容过程中读写均无停机，这个解读是否正确？

日志详细分析与结论 #

时序梳理（按UTC+01时间线） #

• 16:41-16:43：第一次跨AZ故障转移+原Writer缩容启动
  16:41原Writer（tracker-rds-uat-0）开始执行R5→T3的实例类修改；16:42启动跨AZ故障转移，将Reader（tracker-rds-uat-1）提升为Writer，同时原Writer关机，Reader先关机再重启完成角色切换；16:43故障转移完成，tracker-rds-uat-1正式成为新Writer。
• 16:47：新Writer完成缩容
  tracker-rds-uat-1完成R5→T3的实例类修改并重启，此时它已是T3规格的Writer。
• 16:49：第二次故障转移+原Writer转Reader并完成缩容
  启动故障转移将原Writer（tracker-rds-uat-0）重新提升为Writer；tracker-rds-1收到新Writer晋升通知后，关机再重启转为Reader；同时tracker-rds-0完成实例类修改后关机重启，切换为T3规格Writer，故障转移随即完成。
• 16:49-16:56：Reader完成最后配置
  tracker-rds-1作为Reader执行实例类修改，完成后重启；后续更新参数组，全部缩容操作完成。

停机判定结论 #

你的初步解读基本正确，缩容过程中读写服务均无业务级停机：

• 写入服务：两次故障转移都是Aurora原生快速故障转移，切换时间在秒级，集群会自动路由流量到新Writer，不会出现长时间写入中断。
• 读取服务：Reader转Writer期间，读流量会自动切换到新Writer（Aurora Writer支持读请求）；后续Reader重启时，读流量也可临时路由到Writer，不会出现读服务完全中断的情况。

需要注意的是，故障转移和实例重启过程中可能出现极短时间的连接闪断（秒级），但不属于业务级停机，大部分应用的连接池机制可自动恢复这类闪断。

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