【案例】

以近期XX公司迁移到UCloud项目为例，割接时间只有凌晨12点到早上6点的6个小时，中间需要进行应用配置和业务测试，留给数据校验的时间不多，所以早在数据割接之前就启动了sync_diff_inspector对实体数据进行校验。结果数据校验时间和效果都如前预料，最大一个500G数据库的实体数据校验花费了1天多的时间，同时多个数据库的校验也发现了少量的不一致，这一部分不一致经过人工对比后发现实际一致。随后在割接过程中进行元数据校验，结果随着消息队列完成消费和定时任务结束，两边的select max(id)或者select count(id)结果最终一致了。

2、割接与回滚

在割接阶段，不得不考虑的一个问题就是回滚，在割接过程中发现数据确实出现了不一致，这时就需要对不一致的范围做合理的评估。如果在割接时间窗口中的元数据校验如果发现不一致，这时候最明智的处理手段就是回滚，而保障原平台没有脏数据则是回滚的基础。

【案例】

以xx公司迁移到UCloud为例，在托管IDC迁移到UCloud混合云的过程中，由于业务依赖较少，所以采用了可以敏捷割接和回滚的业务模块迁移方式。在这一案例的割接实践中，运维团队不仅为数据库设置了只读，而且也在业务应用中嵌入了只读开关，只要通过配置中心发布开启只读开关即可生效。在数据库只读后就参考数据同步阶段的数据校验方式，对数据或者元数据进行校验，最后在确认应用的读取功能都正常以后再解除目标库的只读，并开放业务。在这个案例中回滚也是相对简单的，如果发现应用的读取功能异常，这时候只需将应用重新部署回原平台，启动和解除数据库只读即可。

而对于需要进行整体割接的任务，割接过程相比于模块化的割接会复杂一些，但是与模块化割接的机理大同小异。在割接过程中先通过停用负载均衡、设置ACL的方式停止业务入口，等待消息队列完成消费数据落地以及定时任务运行完成，然后参考割接准备阶段的方法对原平台数据进行保护。在完成原平台的数据封存后，需要等待同步任务最终完成同步以及对数据进行校验，具体的数据校验方法是参考前文中数据校验方法完成的。在确认两边平台数据一致后，就可以停止同步，在新平台启动应用和进行内部测试。

至于回滚操作，本身也是有时间边界的，当新平台业务入口做了灰度开放后就不能进行回滚操作了，因为这时候有很大机率真正的客户数据已经写入到新平台，但是这部分新数据又没有同步回原平台，这样两边数据就是不一致的。但是一般而言，只要保证迁移两边平台数据是一致的，应用程序大多是应用状态或者代码逻辑问题，相对可控。

写在最后

多云部署已成趋势，在帮助平台用户进行多云部署和数据迁移的过程中，UCloud技术团队摸索和积累了丰富的实战经验。为了在有限的业务窗口期将海量数据进行迁移， UCloud服务器迁移中心USMC和数据传输工具UDTS，助力用户在保证数据完整性和一致性的前提下，大大提升了多云部署的数据同步效率。

以上就是UCloud华南架构团队关于跨云迁移在数据同步、规整和割接过程中保障数据一致性的一些实践和思考，希望对遇到同类问题的大家有所帮助。当然，本文所阐述的数据迁移同步的解决方案也适用于本地IDC迁移上云的场景。