如何处理Amazon Aurora Postgres自动缩容时客户端持有的副本连接？

• 强制使用集群Reader端点而非单个副本地址
  永远不要让客户端直接连接单个只读副本的IP或私有DNS，必须使用Aurora集群的Reader端点。Aurora会自动维护这个端点的后端副本列表，当某个副本被标记为缩容时，服务会逐步将流量从该副本剥离，新的连接会被路由到其他健康副本。已有的连接在副本终止前会被Aurora主动断开，但客户端通过Reader端点重新建立连接时会自动命中可用副本。

• 客户端实现连接重试与失效转移逻辑
  在应用代码中捕获连接断开、超时这类异常，实现带指数退避的重试机制——第一次重试间隔1秒，第二次2秒，最多重试3-5次，避免短时间内大量请求压垮剩余副本。同时，连接池不要复用已失效的连接，每次获取连接前可以执行SELECT 1做心跳检测，确保连接可用。

• 利用CloudWatch事件提前感知缩容动作
  Aurora在缩容只读副本前会发送CloudWatch事件（事件类型为AWS::RDS::DBInstance的DeleteStart）。你可以通过Lambda函数订阅这个事件，然后触发内部通知机制（比如给应用服务发HTTP请求、推送消息到消息队列），让应用层提前主动释放指向待删除副本的闲置连接，减少被动断开带来的影响。

• 优化连接池与超时配置
  调整客户端连接池的参数：设置较短的连接超时（比如5秒），避免客户端长时间卡在失效连接上；配置闲置连接回收规则，比如每5分钟回收一次闲置超过10分钟的连接，确保连接池里的连接都是指向当前可用副本的。

• 主动测试缩容场景
  定期手动触发一次副本缩容操作，模拟生产环境的缩容场景，验证客户端的重试逻辑、连接转移是否正常工作，同时检查应用是否会出现未处理的异常、数据丢失等问题，提前修复潜在漏洞。

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