迁移表同步问题分析

云数据库基本上都会提供数据迁移的服务。以方便用户迁移。例如阿里云厂商的 DTS 服务。

在迁移数据的过程中，对应工具会进行。

• 结构迁移
• 全量数据迁移
• 增量数据迁移

全量迁移开始后会激活增量数据读取模块获取并保存全量数据迁移过程中发生的数据更新。在全量数据迁移完成后，工具会把迁移过程中保存的数据更新数据同步到目标数据库中。对应的操作会不断重复直到源数据库和目标数据库完全同步。

时间往往仅差 1 ～ 2s。如果当前业务针对数据的实时性的要求不是那么高，查询接口可以在全量迁移后直接替换到新的数据库。

但针对数据修改接口来说并非那么简单。如果线上服务有多个 Pod。在进行服务发布时，有可能会丢失信息，这是因为在主键自增的情况下。增量复制和线上服务插入会导致 id 重复。那么就有可能出现数据在新表插入失败。

由于用户在更改源数据表时肯定会成功的，但在数据表迁移过程中可能会丢失该条数据，用户在此基础上进行一系列操作都会出问题（例如用户会去更新新数据表，而新数据表中 id 对应的数据并非插入的那一条）。

针对这种情况，开发者该如何处理呢？

可以基于业务数据增长跳过一段 id，比如目前表 id 最大 1000，那么可以设置迁移表自增长 id 为 10000。这样就不会有这种问题。

或者在建立迁移表时不用 id 作为主键，而是使用 id + 操作者 id 作为新表的主键。这样就大大减少了主键冲突的可能。同一时刻同一个操作者同时操作两条数据是不大可能的。在等到线上 Pod 发布完成后，开发者再进行一次数据整理然后把主键改回 id 即可。迁移写入前建议用户更新或者查询建议都使用 id + 操作者 id 进行处理，这样就不会出现数据异常。

有时候迁移服务不会一刀切，此时还需要工具实现双向同步。

对应的服务升级建议放在深夜，对用户影响较小。