Brex 数据库灾难恢复

Source: Dev.to

引言

Brex 是一个金融操作系统平台，提供企业卡、费用管理、差旅、账单支付和银行服务。在最近的 AWS FSI Meetup 上，工程经理和团队成员讨论了他们如何利用 Amazon Aurora Global Database 提高弹性并支持国际扩张。

灾难恢复的重要性

团队强调需要为灾难场景做好基础设施准备，重点在数据层。他们的技术栈主要使用 PostgreSQL、PgBouncer 和读副本，服务于应用和分析工作负载。此前，灾难恢复（DR）过程是手动且耗时的。

DR 方案的目标

• 实施 warm DR 方案，以降低 恢复时间目标 (RTO) 和 恢复点目标 (RPO)。
• 通过分析指标、当前能力和大量测试，定义可接受的 RTO/RPO 值。
• 确保应用能够容忍在故障转移期间出现的额外延迟或数据丢失。

选择 Amazon Aurora Global Database 的原因

Aurora Global Database 提供了所需功能，且对现有架构的改动最小，允许在需要时使用次要区域。

当前实现的注意事项

• 为只读工作负载使用了自定义 DNS 端点，服务于应用和分析查询。
• 从 PostgreSQL 迁移到 Aurora 存在停机风险。

迁移挑战与方法

团队侧重于自动化，以最小化手动步骤：

1. 构建了一个 Temporal workflow，运行自动化作业，验证每个迁移步骤并准备目标环境。
2. 在工作流确认数据库状态后，进行受控切换到 Aurora Global。
3. 利用 AWS 提供的短暂停机窗口（2‑3 分钟）调整端点和客户端连接。

使用 Temporal 工作流进行自动化

迁移前

• Application → PgBouncer → PostgreSQL primary & replica

迁移过程

• 创建了零停机的 Aurora 只读副本。
• 将副本提升为 global writer 端点。
• 更新 PgBouncer 指向 Aurora global writer。
• 可选地，为多区域部署预置额外集群。

其他工具与流程

• Flux – 通过 GitOps 保持 Kubernetes 集群同步。工作流提前生成 Flux Pull Request，并在人工验证后合并。
• Terraform – 模板化创建 Aurora global 集群并管理读实例。
• Internal CLI – 为团队提供自助命令，以触发 Aurora 集群的故障转移（非计划中断）或切换（计划维护）。

提升工作流性能

• 初始端到端自动化耗时约 15 分钟。
• 引入并行步骤（如获取凭证、创建 Flux PR）将运行时间缩短至约 10 分钟。
• 添加 dry‑run flag 以进行非破坏性测试。
• 最终优化，包括预创建 Flux PR 和减少 Git 操作，使总时间降至 3 分钟。

经验教训

• 在生产迁移前，必须在预演环境中进行充分测试。
• 自动化降低人为错误，并实现跨多个数据库的可重复流程。
• 干跑迁移有助于在不影响生产的情况下验证工作流。
• 通过每周迁移少量数据库的迭代改进，使团队能够持续优化流程。

---

本文概述了 Brex 工程团队在使用 Amazon Aurora、Terraform、Flux 和 Temporal 实现灾难恢复自动化时的关键要点。