Plaid | 数据库切换历程：从 AWS Aurora MySQL 到 TiDB 的迁移之旅

原文来源： https://tidb.net/blog/231f2752

原文链接： https://plaid.com/blog/switching-to-tidb/ 翻译能力来自：Deepseek （ai.com ）

作者：Zander Hill

Zander Hill 是 Plaid 的软件工程师和前工程负责人，曾创立在线存储团队，并在大规模数据库系统领域拥有丰富经验。他擅长减少停机时间、降低成本，并带领团队完成复杂的数据库迁移项目，其执行速度常被供应商称为“过于激进甚至疯狂”。

导言

Plaid 是一家美国的金融科技公司，2024 年 4 月以 920 亿人民币估值入选《2024・胡润全球独角兽榜》，截至 2024 年 3 月，已在全球 17 个国家内为超过 8000 个应用程序和服务提供支持，链接超 12000 家金融机构，拥有超 1 亿活跃用户，每三个美国成年人中就有一个曾使用 Plaid 的服务来连接其金融账户。

更换数据库平台是现代基础设施中最艰巨的挑战之一。它需要严格的规划以确保数据一致性、服务可用性，并保持性能和功能的兼容性。2023 年 1 月，我们启动了“SQL 的未来”项目，旨在为 Plaid 未来 5 到 10 年的增长奠定在线关系型数据库基础。如今，我们已成功将大部分服务从 AWS Aurora MySQL 迁移至 TiDB，几乎未影响业务运行，并开始收获这一投资的成果。

本文分享我们的迁移过程，希望能为面临类似基础设施改造挑战的企业提供参考。

动机

作为 Plaid 存储团队的创始人，我观察到 Aurora MySQL 的投入与自托管系统的局限性。Plaid 存储团队负责为公司的在线数据提供可扩展且可靠的存储平台，覆盖关系型数据库、NoSQL 和缓存系统。

我与架构负责人 Joy Zheng 和数据库技术专家 Mingjian Liu 共同设计了评估替代方案的框架，并制定了雄心勃勃的时间表：

• 1 个季度 ：技术调研
• 1 个季度 ：原型验证
• 目标 ：在 AWS MySQL 5.7 停用前完成新平台迁移！

为确保项目价值，我们设定了一个硬性约束：**全公司迁移周期不超过两年**。

技术背景

• 总在线存储规模 ：约 800 台服务器、50 万 QPS、650 TB 数据，内部 SLA 为 99.99%+ 可用性。
• SQL 平台 ：约 446 台服务器、14 万 QPS、40 TB 数据，SLA 为 99.99%+。
• TiDB 当前规模 ：约 160 台服务器、17 万 QPS、70 TB 数据、700+ 集群虚拟 CPU。
• 团队规模 ：存储团队 6 名软件工程师。

为何放弃 Aurora MySQL？

1. 可靠性挑战

   1. Aurora 的单写入架构成为单点故障，配置变更、扩缩容、重启和故障转移期间易引发停机。
   2. 分散的数据库运维难以规模化，需集中化管理并增强可靠性保障。

2. 开发效率低下

   1. 写入吞吐瓶颈（如高行争用场景下单表写入约 1.2 万次/秒）。
   2. 在线 Schema 变更困难，团队常通过新增表规避维护窗口。
   3. 每年需投入 2 人年 解决 Aurora 的限制（尤其是 2–10+ TB 的大表）。

3. 高维护成本

   1. 2023 年耗费 2 个季度 从 MySQL 5.6 升级至 5.7，每次升级或常规操作（如启用 Binlog、调整规格）均需分钟级停机。

4. 分片与扩展需求

   1. Aurora 写入扩展能力有限，TiDB 的自动分片能力可支持持续高性能写入。

5. MySQL 5.7 停用

   1. 社区支持终止，Aurora 的 EOL 临近。基于 Facebook 的 MySQL 8.0 升级经验，我们决定将升级精力转向平台迁移。

迁移时间线概览

• 2023 Q1 ：评估替代 Aurora MySQL 5.7 的方案。
• 2023 Q2 ：完成 TiDB 概念验证（PoC）。
• 2023 Q3 ：敲定技术方案（RFC），争取资源支持并搭建 TiDB 基础设施。
• 2023 Q4 – 2024 Q1 ：首个服务迁移至 TiDB，随后扩展至约 17 个服务。
• 2025 年 1 月 ：完成 41 个服务迁移。
• 未来 ：计划 2025 年中完成全部迁移。

---

服务迁移流程

单服务迁移可分解为数百个微步骤，内部操作手册包含约 200 项任务 和 **20 个子手册**。总体分为四阶段：**消除兼容性问题 → 数据复制 → 验证 → 切换**。

1. 消除兼容性问题

• 强制主键 ：TiCDC（TiDB 的变更数据捕获机制）依赖主键实现一致性复制，无主键表需服务团队补充。
• 移除外键 ：TiDB 生态工具部分不支持外键，需在应用层实现逻辑约束。
• 审核事务隔离级别 ：TiDB 不支持 SERIALIZABLE 隔离级别，需调整为 SNAPSHOT ISOLATION（可重复读）。
• 审核自增字段 ：TiDB 的自增 ID 非全局单调（因多节点分配范围），依赖严格递增 ID 的服务需改用时间戳排序或重构 ID 生成逻辑。
• 验证兼容性 ：在自动化测试中切换至 TiDB，生产环境切换前暂停 Schema 变更。

2. 数据复制

• 使用 TiDB Lightning 快照导入数据至 TiDB。
• 克隆 Aurora 数据至回滚集群，建立原库、TiDB、回滚库的复制链路。
• 集成 **“mysql/tidb/rollback mysql” 切换客户端**，通过功能开关实现数据库端点动态切换。

3. 验证

• 数据一致性检查 ：使用 TiDB 的 sync-diff-inspector 等工具确保数据完全匹配（曾发现二进制主键和时间戳列的边缘案例，需 PingCAP 提供补丁）。
• 实时查询验证 ：通过双写双读对比正确性与性能，优化 TiDB 的查询计划（如索引提示）。
• 性能基准测试 ：确保高流量服务（Tier 0/1）的延迟符合预期。

4. 切换

• 通过功能开关实现原子切换：

  • 暂停 Aurora 写入，等待复制完全同步。
  • 切换读流量至 TiDB。
  • 执行安全性与正确性验证。
  • 切换写流量至 TiDB。

• 整个过程仅需 **约 60 秒写入停机**，读流量全程可用且一致。若切换后出现问题，可快速回滚至专用 MySQL 集群。

效率提升策略

面对数十个待迁移服务，我们优化策略如下：

原则

• 优先攻克最难的服务
• 始终备有回滚计划

工具创新

• 动态运行手册（Dynamic Runbooks）

  • 将 Markdown 指令与 TypeScript 代码嵌入 Jupyter Notebook，实现文档与脚本的深度融合。
  • 使用 Deno 语言（团队熟悉 TypeScript、依赖管理简单、无虚拟环境负担）开发 CLI 工具，支持参数输入与执行日志实时上报至 Slack。
  • 效率提升：切换阶段提速 **5 倍**，服务迁移整体提速 **3-4 倍**（200 个步骤）。

集中化与自动化

• 任务集中化 ：原由客户端团队处理的步骤（如环境切换、Schema 变更）转由存储团队统一执行，减少上下文切换开销。
• 批量处理常规步骤 ：通过自动化减少重复劳动。

---

经验总结

成功之处

• 性能验证准确 ：迁移前基准测试结果与实际表现高度一致。
• 零停机升级与扩展 ：一周内完成 6 个生产集群升级，TiDB 二次升级仅需 2 天（Aurora 需 6 个月且伴随分钟级停机）。
• 在线 Schema 变更 ：无需维护窗口即可修改 5+ TB 表的 Schema。
• 供应商支持 ：PingCAP 工程师（特别感谢 Michael Zhang）响应迅速，提供补丁与建议。

改进空间

• 生态工具完善性 ：TiCDC、TiDB Lightning 等工具存在边缘案例，需投入时间修复。
• 查询计划差异 ：部分查询因 TiDB 执行计划不同导致全表扫描，需通过查询提示优化。
• 资源隔离与配置复杂度 ：TiDB 资源控制灵活但配置交互复杂，需结合源码理解最佳实践。

结语

通过动态运行手册、周密规划和团队高效执行，我们的服务切换周期从 3-4 周 缩短至 **约 1 周**，写入停机时间从 5 分钟 降至 **60 秒**。TiDB 的横向扩展能力、无锁 DDL、更优可观测性及简化运维，已为 Plaid 带来显著收益。

数据库迁移绝非易事，但通过以下策略可大幅降低难度：

1. 充分规划与早期测试 ：覆盖数据正确性与性能验证。
2. 自动化重复任务 ：标准化流程，减少人工干预，保留回滚路径。
3. 优先攻克边缘案例 ：长期收益显著。
4. 高效沟通 ：与客户端团队、管理层及供应商保持紧密协作。

Plaid 存储团队（由赞德·希尔和 Andrew Chen 领导）在 PingCAP 2024 HTAP 峰会上分享了此次迁移经验。我们相信，TiDB 将支撑未来 5 到 10 年的存储需求，助力团队无需维护窗口、灵活应对生产事件，并加速产品创新。

致谢

• 存储团队 ：Zander Hill（负责人）、Mingjian Liu（技术主管）、Andrew Chen（工程经理）、Lauren McCarty、Brian Xie、Seyoung Kim、Catherine Shen、Lohit Verma（项目经理）。
• 架构指导 ：Joy Zheng（平台架构负责人）提供技术审阅并推动制定运维原则。