跨区域AWS高可用架构：PostgreSQL RDS自动读写切换配置问询

针对你提出的跨区域高可用需求，以下是无需手动干预的架构实现方案，覆盖数据库同步、故障自动切换及恢复后数据同步全流程：

一、核心架构改造 #

1. 数据库层：双向逻辑复制实现双活同步 #

• REGION-1：保留现有多AZ PostgreSQL RDS主库，修改参数组开启rds.logical_replication=1，重启生效后创建具备REPLICATION权限的复制用户。
• REGION-2：将原只读副本升级为独立的多AZ PostgreSQL RDS实例，配置与主库一致的参数组（同样开启逻辑复制）。
• 建立双向逻辑复制通道：
  • 从REGION-1主库到REGION-2实例：创建发布（PUBLICATION）包含所有业务表，在REGION-2实例创建订阅（SUBSCRIPTION）拉取主库数据。
  • 从REGION-2实例到REGION-1主库：创建仅包含REGION-2本地写操作的发布（可通过触发器或复制槽过滤重复数据），在REGION-1主库创建订阅同步回来。

2. 流量自动切换：Route 53健康检查+权重路由 #

• 为两个区域的负载均衡配置统一域名，通过Route 53加权路由分配流量：
  • 默认状态下REGION-1权重设为100，REGION-2设为0（或低权重用于流量灰度）。
  • 配置Route 53健康检查，同时监控REGION-1的RDS主库状态（通过自定义端口或数据库连接检查）和负载均衡可用性。
  • 当REGION-1健康检查连续失败时，Route 53自动调整权重：REGION-1设为0，REGION-2设为100，流量无缝切换至REGION-2。

3. 自动化故障切换与恢复：Lambda+CloudWatch Events #

• 故障触发逻辑：
  • 配置CloudWatch Events监听RDS主库的故障事件（如RDS-EVENT-0099主库故障切换）或自定义健康检查告警，触发Lambda函数。
  • Lambda执行操作：停止REGION-1到REGION-2的复制，确认REGION-2实例的读写权限（独立实例默认已具备），记录切换时间戳用于后续数据校验。
• 恢复同步逻辑：
  • 当CloudWatch检测到REGION-1主库恢复健康后，触发另一Lambda函数：
    1. 停止REGION-2到REGION-1的复制。
    2. 以REGION-2实例为源，创建REGION-1主库的临时订阅，同步故障期间REGION-2产生的数据。
    3. 数据校验一致后，恢复双向逻辑复制通道。
    4. 逐步调整Route 53权重，将流量切回REGION-1（或保持双活模式）。

二、关键细节处理 #

• 写冲突解决：
  • 为业务表添加last_updated_at字段，同步时保留时间戳最新的记录；或在应用层划分写操作的区域归属，避免同一数据在两个区域同时被修改。
• 复制监控：
  • 通过CloudWatch监控逻辑复制的延迟指标（replication_lag）和复制槽状态，当延迟超过阈值时触发告警。
• 权限与安全：
  • 复制用户仅赋予必要的REPLICATION和LOGICAL_REPLICATION权限，通过VPC peering或AWS Direct Connect建立跨区域数据库连接，避免公网传输。

三、备选简化方案：Aurora Global Database #

若业务允许切换到Aurora PostgreSQL，可直接使用Aurora Global Database原生实现跨区域高可用：

• REGION-1部署可读写的主集群（多AZ），REGION-2部署只读副本集群。
• 当REGION-1故障时，可一键（或通过Lambda自动）将REGION-2的副本集群提升为可读写主集群，RTO通常小于1分钟。
• 原主集群恢复后，可自动重新连接为副本集群，同步REGION-2产生的数据。
• 结合Route 53健康检查，无需自定义复杂的复制逻辑即可实现全自动流量切换。

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