这是学习笔记的第 1929 篇文章
最近对一个业务系统的迁移做了初步尝试，可以参考之前的一些测试内容：
对测试过程分析来看，是需要把业务从原来的SQLServer环境迁移到3套MySQL分布式集群，如下图所示：
整个数据迁移如果按照这个步骤，会存在一些不可控因素：
1）迁移时间过长，数据迁移的常规时间都是小时级的，如果动辄5个小时，是明显不符合需求的。
2）一次性迁移三套集群环境还是存在风险，没有完善的检验机制，是很难有说服力的。
3）迁移步骤存在过多的瓶颈因素，比如网络带宽，比如数据写入性能，这些因素的代价太高，对个人的依赖较重。
所以如果要缩短维护时间，同时能够保证数据的完整性，我们就需要对数据流转上下一些功夫，首先这个业务的模型相对简单，几乎不存在多表关联和数据删除类操作，只有基本的insert,select,update操作。
那么基准数据是基于用户维度，比如有1000万用户，那么这1000万用户的业务数据是可以完整追溯的，在目前的业务中，多是覆盖型数据写入。所以我们要满足需求的一个方式就是通过增量恢复来不断的回放数据，直到数据迁移的维护窗口，把数据写入入口切换即可。
整个步骤分为了两个阶段：
1）第一个阶段是直接把历史型数据写入的入口打开，即业务同时在SQLServer和MySQL的历史数据集群写入。这个过程是不需要单独的维护窗口的。 可以迅速验证接入业务系统后的数据情况和压力。
2）第二个阶段是把变更的数据追平，在维护窗口完成数据入口的切换。
这个阶段的一个思路是业务对写入的数据可以追加到数据队列中，比如userid1:100,101,102,即3个用户的业务数据发生了变化，然后不断的使用SQL Server的快照恢复来得到基于一个时间点的数据，通过这个数据队列的数据和快照数据提取比对，得到变更后的数据明细，应用到已有的分布式数据集群中。
不断的重复这个过程，假设原来的基数是1000万用户，那么在低峰期的数据变化要少得多，比如是10万，那么快速应用这些增量变化是相对容易可控的。
通过以上的方式基本可以实现数据的平滑切换，而且对于业务来说，也是一个循序渐进的替换过程。
相关链接：