数据规整阶段

1、脏数据处理

正如前面提到，为了了解新平台中应用是否能正常运行，一般来说迁移过程中涉及到的应用测试都会尽量使用真实数据，甚至采用流量重放的方法对新系统进行测试，以便通过对比原平台环境中真实行为的结果来校验新平台应用是否正常工作。

在测试之后，新平台就会出现脏数据，需要对其进行处理。通常脏数据的处理有两种思路可以使用，其一是回滚，就是在开展业务测试前先对数据进行备份或者记录还原点。对于MySQL数据库可以基于binlog进行回滚，也可以通过云平台能力进行数据库备份和回滚，但是需要注意备份时暂停UDTS任务以及其它写入，以及记录binlog位置。对于文件存储和对象存储，文件变更日志的作用就很显著了，所有变更过的文件从日志中解析出来之后从源头重新同步，这样可以避免所有文件的重新同步。

当然也可以丢掉全部脏数据，采取与数据同步阶段相同的数据迁移手段对数据进行重新同步，这样虽然慢一些，但是整个数据同步过程就是幂等的，可重复性更强。两种脏数据的处理方式可以根据实际数据量灵活采用。

2、保障数据一致性

在割接准备阶段时候进行的数据同步所得到的数据就是割接和割接后的生产数据了，所以需要通过一定的手段，保障数据的持续同步，同时避免数据被意外修改。下面说说几种保障的办法。

→ 基于用户的数据库只读

对于MySQL而言，通过对数据同步和业务应用设置不同的账户，并且对不同用户分配不同的权限，这几乎是最简单易行的实践方式。设立数据同步账户，赋予增删查改权限和DDL语句的权限，这样可以满足存量和增量数据同步的需要，然后将数据同步账户严格控制只配置给UDTS数据同步工具和sync_diff_inspector数据校验工具。

而对于业务应用的配置文件，或者记录到配置中心中的配置，上面所使用的数据库账户就只分配select语句权限，这样就能保障业务应用、脚本或者各种定时任务都无法对数据进行更改。而且这样做还有一个好处，对于一些没有实现数据库重连逻辑的业务应用，这时候数据库是可以正常连接的，这意味着在数据割接的时候不需要重启应用，而是只需要调整MySQL中业务账户的权限。

对于一些场景，不重启对于割接过程来说是非常重要的。例如由于分布式框架的引入，对象和方法可以轻松的通过RPC获取，这时候业务团队也专注于业务的实现，忽略了底层重连机制的实现。结果就是应用系统成为了一个分布式的紧耦合系统，主机A上某个进程的正常运行需要依赖主机B上进程的正常运行，而且B还不能随便重启，因为重启后A不会重连。这时候如果应用不用重启，那意味着清理脏数据后，应用保持当前的运行状态即可，而不是调查所有应用的启动顺序，在割接时确认数据同步后再按顺序逐个启动，这样有利于提升割接后的业务稳定性和降低割接操作的复杂度。

然而，通过数据库只读来保障数据一致性的方式受限也会比较多，例如MySQL有基于用户的只读方法，同时Redis、SQLServer、MongoDB、Elastic Search、文件存储、对象存储等等组件又有各自不同的只读方法，在组件数量和种类增加以后，这种操作方式的优势会逐渐丧失。

因此，数据库只读的方式适用于MySQL数据库且实例数量不多的情况，例如整体迁移以模块化方式进行的情况。另外对于需要尽量减少应用重启的系统也可以优先考虑这种方式来保障数据一致性。

→ 结束应用进程

前面提到，在一些应用系统里重启应用并不是易事，但有一些应用系统，重启造成的困扰并没有那么大，可以相对自由的重启应用。实际上对于一个系统而言，会有三类程序可能对数据存储进行修改，分别是应用程序和操作系统定时任务脚本，对于数据库而言还需要多加一个定时任务。只需要保证这三类程序都是停止的，那么就可以保证没有同步服务以外的程序对数据进行修改，从而保障数据一致性。