FSI Meetup 2025 年第四季度 - Brex 数据库灾难恢复

场次笔记

Brex 简介

• 用于管理费用、差旅和信贷的财务运营系统平台。
• 工程经理和团队成员探讨如何利用 Amazon Aurora 提高弹性并支持国际扩张

Brex 服务

• 企业卡、费用管理、差旅、账单支付和银行业务
• 旨在帮助客户明智、合理地支出

为灾难场景做好基础设施准备的重要性

• 重点关注数据层，主要使用 PostgreSQL，并通过 PG bouncer 和副本支持应用及分析用途
• 将较小的数据库合并到单个数据库实例中
• 过去的灾难恢复流程依赖人工操作且耗时较长

灾难恢复解决方案的目标

• 采用温备灾难恢复解决方案，以缩短恢复时间目标（RTO）并降低恢复点目标（RPO）
• RTO：灾难发生后恢复正常运营所允许的最长时间
• RPO：可容忍的最大数据丢失量

确定 RPO 和 RTO

• 分析指标、评估当前能力并开展广泛测试
• 了解应用将如何应对额外的延迟和数据丢失

选择 Amazon Aurora Global Database

• 无需大幅更改当前设置即可提供所需功能
• 可在需要时使用辅助区域

当前实施中的注意事项

• 为读取应用创建自定义 DNS 端点，供应用和分析用途共同使用

迁移挑战与方案

• 由于可能导致应用停机，从 PostgreSQL 迁移到 Aurora 存在困难
• 专注于自动化，以尽量减少人工处理
• 构建 Temporal 工作流，用于运行自动化任务、验证迁移步骤并准备环境
• 在自动化流程确认数据库状态无误后，完成向 Aurora Global 的切换

迁移期间的停机管理

• AWS 为迁移提供了一个较短的停机窗口（2–3 分钟）
• 利用此窗口调整端点以及使用该数据库的应用
• 借助短暂的停机时段实现平稳过渡

使用 Temporal 工作流实现自动化

迁移前的当前状态

• 应用连接到 PG bouncer，后者连接到 PostgreSQL 实例和副本实例

迁移流程

• 通过 AWS 创建 Aurora 只读副本，且无需停机
• 工作流提升 Aurora 只读副本，并创建 Aurora 全局集群
• 应用连接到 PG bouncer，后者再使用全局写入器端点连接到 Aurora 全局集群
• 可以再创建一个集群，以构建多区域环境

Flux：

• 通过 git 存储库保持 Kubernetes 集群同步的工具
• 工作流预先生成 Flux git 拉取请求
• 人工验证后，工作流自动合并拉取请求
• 向工作流发送确认信号，使其继续执行停机操作并提升 Aurora 全局集群

使用 AI 自动审查 Flux

• 识别拉取请求中的错误或问题，并提供审查意见

试运行迁移标志

• 可在不触发破坏性操作或停机的情况下测试迁移
• 预先创建 Flux git 拉取请求以供审查，但不合并请求或提升集群

迁移中使用的其他工具和流程

• Terraform：创建用于将数据库作为新全局集群进行管理的模板
• 迁移工作流完成后，为每个数据库添加 Terraform 配置
• 通过 Terraform 管理全局集群中的读取器实例

内部命令行工具：

• 添加命令，使团队能够以自助方式为其 Aurora 全局集群执行切换或故障转移
• 故障转移：用于从非计划中断中恢复；当一个区域停机时，切换到其他区域
• 切换：用于运营维护或计划内操作等受控场景，不会丢失数据

通过迭代提升工作流性能的历程

• 最初的工作流完成端到端自动化大约需要 15 分钟
• 提升 Aurora 全局集群并创建 Flux git 拉取请求时会出现停机
• 流程按顺序执行，未进行并行化

引入并行化后，工作流耗时缩短至 10 分钟

• 更新工作流以并行执行步骤，包括获取凭证和预先创建 Flux 拉取请求
• 引入试运行标志，用于对迁移进行非破坏性测试

最终重构工作流后，执行时间缩短至 3 分钟

• 预先创建 Flux 拉取请求，使工作流可以暂停并等待停机窗口
• 减少 git add 操作以降低成本
• 添加信号命令，以受控方式启动停机

实施过程中获得的经验

• 在正式迁移前进行全面测试和审慎部署至关重要
• 从预发布环境开始，解决问题后再进入生产环境
• 自动化可减少人为错误，并能轻松复制到多个数据库
• 使用试运行选项模拟迁移，以便在不造成停机的情况下测试工作流（试运行或演练是一种软件测试过程，用于确保系统能够正常工作且不会导致严重故障。）
• 每周迁移少量数据库，通过迭代持续改进