数据迁移流程的优化
完整的的的这是学习笔记的第 2029 篇文章
昨天做了一个数据迁移流程的优化，直到发生了一些严重的问题，才明显重视起来这个问题。
整个流程图大体如下，应用层面的支撑能力很强，可以支持数据的双写，所以我们把重点放在数据迁移（物理迁移，逻辑迁移）层面，而是更多在流程控制方面。
整个流程简单来说分为2个大的步骤，数据一次全量，后续始终是增量，全量考虑异构数据库的特点，也是采用了datax来做流转，假设全量同步的时间为T1,则在T2时间应用开始开通数据通道，使得数据能够同时写入SQL Server和MySQL,然后考虑到T1~T2之间的数据会丢失，则需要再做一次T1开始的增量数据同步。
看起来流程是完整的，但是细想，在T3开始做数据增量同步的时候，T2时间已经开始应用层面的数据双写，这会导致有些数据写入被影响，因为T3开始的增量同步涉及的数据变更范围比较大。在同步的过程中同时又有大量的数据写入和在线稽核，很可能出现数据的问题，而直接的影响则是同步的过程没有做分片控制，导致一半的节点的主从复制都失败了。
这个问题算是给我们敲响了警钟，我们树立了一个基本原则，不允许线上的数据操作引入数据同步（datax）。明确了这一点，我们把整个流程改进为如下的方式：
T3这个时间点我们再次做数据增量同步，然后在T4这个时间点开始做数据的离线稽核，数据是写入Staging的离线库中的，稽核的逻辑相对简单：线上库中已存在，则跳过，如果不存在则写入。这个稽核过程不要求实时性，即只要完成即可。而重要的部分则是后续的在线稽核，即程序会对写入的数据和源SQL Server做比对，如果两边数据不一致，则以SQL Server的为准，这样数据经过一段时间的修复之后会逐步追平，而在业务逻辑层面在逐步稳定之后，会切断SQL Server的数据通道，数据只写入MySQL,则完成了整个数据的阶段性迁移。
这个过程也确实牵涉了不少外部的细节，有些数据同步逻辑，事务模型的简化等，有些过程就没有详细展开。
总体来说，我们对于线上环境要存在敬畏之心。
