Azure PaaS服务本地容灾方案咨询（PostgreSQL、Cosmos DB、Redis）

1. Azure Database for PostgreSQL 本地DR方案 #

• 异步流复制+本地PostgreSQL主从架构（优先选）
  具体做法：在OpenStack上部署PostgreSQL主实例，先在Azure内为目标PostgreSQL创建只读副本，通过pg_basebackup生成全量备份并导出到本地实例，之后配置异步流复制，拉取Azure侧的wal日志持续同步。如果要进一步压低RPO，可开启半同步复制（需确认Azure PostgreSQL的wal_level设为replica，且max_wal_senders配额充足）。
  RTO/RPO表现：异步复制的RPO可控制在几秒到数分钟，半同步能压到秒级；RTO主要为切换耗时，约5-15分钟（含DNS切换、实例接管）。
  要注意的地方：必须打通Azure与OpenStack的专线或VPN，控制复制延迟；本地实例的CPU、内存、存储规格需与Azure侧匹配，避免成为同步瓶颈；定期演练切换流程，避免故障时手忙脚乱。
• 定时备份+快速恢复（备选）
  如果流复制的网络条件受限，可利用Azure PostgreSQL的自动备份（保留7-35天），定期将备份文件同步到OpenStack Swift对象存储，本地提前部署好PostgreSQL实例，故障时从备份恢复。但该方案RPO为备份间隔（如1小时），RTO更长（30分钟以上），仅适合网络条件极差的场景。

2. Azure Cosmos DB 本地DR方案 #

• 全量初始同步+Change Feed实时增量同步
  具体做法：先用Cosmos DB数据导出工具完成全量数据同步，将数据导入OpenStack上的兼容数据库——若为MongoDB API的Cosmos DB，本地部署MongoDB副本集；若为SQL API，可使用PostgreSQL的JSONB字段存储文档，或选择专用文档数据库。随后通过Cosmos DB的Change Feed捕获实时数据变更，用自定义服务将变更推送到本地数据库。
  RTO/RPO表现：Change Feed可实现近实时同步，RPO在几秒到数分钟；RTO取决于本地数据库的接管时间，约10-20分钟（主要为路由切换耗时）。
  要注意的地方：需处理Change Feed的断点续传，确保数据不丢失；本地数据库必须采用集群架构（如MongoDB副本集），自身保证高可用；若为多区域Cosmos DB，Change Feed订阅需覆盖所有写入区域，避免漏数。
• 定期全量备份+恢复（备选）
  利用Cosmos DB的备份功能导出数据到Azure存储，再同步到OpenStack Swift，本地定期恢复。但该方案RPO为备份间隔，RTO较长，仅作为备选。

3. Redis Cache 本地DR方案 #

• Redis主从复制+哨兵模式（优先选）
  具体做法：在OpenStack上部署3个节点的Redis哨兵集群，同时部署一个Redis从实例，将Azure Redis Cache设为主节点，开启复制功能，让本地从实例同步Azure的数据。哨兵会自动监控Azure Redis的状态，一旦Azure侧故障，立即将本地从实例提升为主节点。
  RTO/RPO表现：异步复制的RPO在几秒内，RTO由哨兵切换时间决定，约1-5分钟，几乎可实现用户无感知。
  要注意的地方：Azure Redis需开启非SSL端口（或使用Redis 6.0+支持的SSL复制），确保复制连接正常；Azure与OpenStack之间优先用专线，控制网络延迟，避免复制滞后；哨兵集群需部署在OpenStack的不同可用区，防止单点故障。
• RDB/AOF备份+快速恢复（备选）
  定期从Azure Redis导出RDB或AOF文件到OpenStack Swift，本地Redis故障时恢复。该方案RPO为备份间隔，RTO约10-15分钟，适合网络不稳定的场景，但优先选主从复制。

通用落地要点 #

• 网络是核心：必须打通Azure到OpenStack的专线或VPN，低延迟、稳定的网络是实现低RTO/RPO的基础，否则同步延迟会拖垮所有方案。
• 监控不能少：部署Prometheus+Grafana监控复制延迟、实例状态、同步进度，一旦出现异常立即告警，避免故障爆发后才发现问题。
• 定期演练：每季度至少开展一次DR切换演练，验证RTO/RPO达标，同时让团队熟悉切换流程，确保故障时能快速响应。
• 资源要匹配：本地OpenStack的实例规格、存储性能需与Azure PaaS对齐，避免因本地资源不足导致同步卡壳。

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