从 AWS Aurora 迁移到 TiDB 的最佳实践

业务挑战

该企业采用亚马逊 AWS 公有云承载业务应用，并在此基础之上搭建了微服务应用架构。业务应用架构由大约 80 个组件构成，使用 Java、Spring Boot 等基础技术及 Amazon Aurora 作为核心数据库，所有的支付交易都传输到 Payment 组件进行管理。

随着业务迅速增长，当 Aurora 数据库遇到许多写入请求时，Binlog 同步会成为瓶颈，在提交过程中，Aurora 数据库等待同步目标返回 ACK，当同步数量增加时，提交延迟也会增加。因此，该企业寻求扩展性更好的云原生数据库方案。

迁移实践

在验证阶段，该企业将实际生产流量克隆到另一个 Aurora 数据库和 TiDB 数据库中，并引入 P6spy 开源框架检查数据的完整性，采用 TiDB Sync-Diff Inspector 工具来检查数据库迁移前后的一致性，以及对多种实例故障、集群故障和可用区故障场景进行模拟验证，通过 TiDB Binlog 工具进行数据同步，可以实现 RPO 趋近于零。

实际迁移中，使用增量的方法逐步增加流量，实际迁移耗时小于 2 小时，未出现任何问题，将服务停机时间降至最低。迁移后经过 3 个多月实际业务的运行考验，TiDB 各项指标均达到预期的目标。

新的交易数据库由 TiDB 集群组成，每个集群包括 PD、TiDB 和 TiKV 组件，每个组件都有多个实例，采用 Pump 和 Drainer 设置同步 Binlog 到从集群和灾备站。多个 TiDB 实例位于不同的 AWS 可用区（Region），同时提升了交易业务的容灾能力。