前期准备
在进行数据迁移之前，一定要做好迁移前的准备。
环境调研，源和目标数据库环境、版本、数据量大小、业务场景、操作系统版本等
方案准备，尽量详细、迁移失败导致源数据库挂了是否有数据备份回退方案
人员角色到齐，数据迁移放在晚上，最好是A/B角色一起参与。
对业务影响范围充分了解，对源数据用monitor命令查看有哪些ip进行了操作(过虑掉ping、info、slowlog的ip)，host转为域名
停机窗口、这段时间要是出现问题怎么处理
检查
对比源和目标的环境（info、uname -a命令）
了解业务的影响范围（monitor、wak、sort等命令，有哪些对源进行了crud）
人员备齐（开发、运维）
源数据的备份，万一迁移的时候源挂了
数据双写，在写源的时候，写一份到目标机器，采用先双写后面增量或者全量补充历史数据的方式。
平滑迁移-双写法方案
主要分为四个步骤。
步骤一：服务进行升级，对“对旧库上的数据修改”（这里的修改，为数据的insert, delete, update），在新库上进行相同的修改操作，这就是所谓的“双写”，主要修改操作包括：
旧库与新库的同时insert
旧库与新库的同时delete
旧库与新库的同时update
由于新库中此时是没有数据的，所以双写旧库与新库中的affect rows可能不一样，不过这完全不影响业务功能，只要不切库，依然是旧库提供业务服务。
这个服务升级风险较小：
写接口是少数接口，改动点较少
新库的写操作执行成功与否，对业务功能没有任何影响
步骤二：研发一个数据迁移工具，进行数据迁移，把旧库中的数据转移到新库中来。
这个小工具的风险较小：
整个过程依然是旧库对线上提供服务
小工具的复杂度较低
任何时间发现问题，都可以把新库中的数据干掉重来
可以限速慢慢迁移，技术同学没有时间压力
数据迁移完成之后，就能够切到新库提供服务了么？
答案是肯定的，因为前置步骤进行了双写，所以理论上数据迁移完之后，新库与旧库的数据应该完全一致。
在一种非常非常非常极限的情况下：
date-migrate-tool刚好从旧库中将某一条数据X取出
在X插入到新库中之前，旧库与新库中刚好对X进行了双delete操作
date-migrate-tool再将X插入到新库中
这样，会出现新库比旧库多出一条数据X。
但无论如何，为了保证数据的一致性，切库之前，还是需要进行数据校验的
步骤三：在数据迁移完成之后，需要使用数据校验的小工具，将旧库和新库中的数据进行比对，完全一致则符合预期，如果出现步骤二中的极限不一致情况，则以旧库中的数据为准。
这个小工具的风险依旧很小：
整个过程依然是旧库对线上提供服务
小工具的复杂度较低
任何时间发现问题，大不了从步骤二开始重来
可以限速慢慢比对数据，技术同学没有时间压力
步骤四：数据完全一致之后，将流量切到新库，完成平滑数据迁移。
至此，升级完毕，整个过程能够持续对线上提供服务，不影响服务的可用性。
总结
针对互联网很多“数据量较大，并发量较大，业务复杂度较高”的业务场景，在
底层表结构变更
分库个数变换
底层存储介质变换
的众多需求下，需要进行数据迁移，完成“平滑迁移数据，迁移过程不停机，保证系统持续服务”的解决方案。
双写法，四个步骤：
服务进行升级，记录“对旧库上的数据修改”进行新库的双写
研发一个数据迁移小工具，进行数据迁移
研发一个数据比对小工具，校验数据一致性
流量切到新库，完成平滑迁移
