AWS Aurora PostgreSQL与RDS PostgreSQL选型咨询：跨区域实时复制及无停机需求

首先得说，你基于需求做出的这个选择非常靠谱——Aurora PostgreSQL确实是满足跨区域实时复制、零停机重新水化/补丁操作的最优选项之一，下面我结合你的具体需求拆解下原因：

核心需求匹配度对比 #

1. 跨区域实时复制与零停机故障转移 #

Aurora的跨区域只读副本是基于持续的日志流同步，延迟基本在秒级，完全符合“实时复制”的要求。如果用Aurora Global Database，跨区域故障转移能做到30秒以内完成，整个过程几乎无感知，业务不会中断。

反观RDS PostgreSQL的跨区域副本，是先基于快照初始化，再追补日志，初始化阶段本身就有延迟；而且故障转移时需要先把副本提升为主实例，这个过程通常要几分钟，必然会导致停机，完全不符合你的零停机要求。

2. 零停机重新水化（Rehydration） #

Aurora的克隆（Clone）功能是关键——它用写时复制技术，秒级就能创建出和原实例数据一致的克隆体，不需要完整复制数据。你可以先把克隆实例作为只读副本运行，确认没问题后再无缝提升为主实例，整个过程几乎没有停机时间。

而RDS PostgreSQL的重新水化，比如从快照恢复后切换流量，得先等实例恢复完成（这个过程耗时取决于数据量），再手动切换，必然会有几分钟的停机窗口，这正是你要规避的问题。

3. 零停机补丁与版本升级 #

Aurora的补丁应用是滚动式的：集群里的实例会逐个被更新，更新期间其他实例正常提供服务，完全零停机。对于大版本升级，你可以先升级只读副本，把流量切到升级后的副本，再升级原主实例，全程做到几乎无中断。

RDS PostgreSQL的补丁升级大概率会触发实例重启，哪怕是多AZ部署，切换到备用实例也可能有短暂的连接中断；大版本升级更是需要预留专门的停机窗口，根本达不到你的零停机要求。

额外注意事项 #

• 如果用Aurora Global Database，要关注跨区域的网络带宽和延迟，确保两个区域之间的网络连接稳定，避免复制延迟过高影响业务。
• 克隆实例的性能和主实例绑定，要根据业务负载合理配置实例规格，避免克隆后出现性能瓶颈。
• 用CloudWatch监控跨区域复制的延迟、实例状态等指标，及时发现并处理异常。

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