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

原文链接：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. Aurora 的单写入架构成为单点故障，配置变更、扩缩容、重启和故障转移期间易引发停机。
2. 分散的数据库运维难以规模化，需集中化管理并增强可靠性保障。
开发效率低下
1. 写入吞吐瓶颈（如高行争用场景下单表写入约 1.2 万次/秒）。
2. 在线 Schema 变更困难，团队常通过新增表规避维护窗口。
3. 每年需投入 2 人年 解决 Aurora 的限制（尤其是 2–10+ TB 的大表）。
高维护成本
1. 2023 年耗费 2 个季度 从 MySQL 5.6 升级至 5.7，每次升级或常规操作（如启用 Binlog、调整规格）均需分钟级停机。
分片与扩展需求
1. Aurora 写入扩展能力有限，TiDB 的自动分片能力可支持持续高性能写入。
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 带来显著收益。

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

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

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（平台架构负责人）提供技术审阅并推动制定运维原则。