1.什么是数据迁移
数据迁移指的是将一批数据从同构存储系统（如MySQLA到MySQLB）或异构存储系统（如MySQL-MongoDB）间搬运迁移。
最简单的数据迁移方式是通过脚本或定时任务将数据进行搬运，亦或是通过类似canal之类的工具进行数据同步。
这种最简单方案在数据量小且系统对数据一致性要求低的情况下可以良好生效，但是对于大数据量的实时在线系统来讲，需要在数据迁移的过程中做好以下三个保障：
在线迁移：迁移应该是在线的迁移，也就是在迁移的同时还会有数据的写入
数据一致性：数据应该保证完整性，也就是说在迁移之后需要保证新的库和旧的库的数据是一致的
可回滚：迁移的过程需要做到可以回滚，这样一旦迁移的过程中出现问题，可以立刻回滚到源库不会对系统的可用性造成影响
2.数据双写迁移方案
数据双写迁移是最常用的一种数据迁移方案，可以保证迁移过程是在线的、迁移前后数据是一致的、迁移过程是可回滚的。数据双写迁移方案分为五大步，分别是：同步、双写、校验、切读、切写。以MySQL数据迁移至MongoDB为例来说明这五大步的流程。
2.1.同步
首先通过Binlog监听工具（如Canal）获取MySQL的全量日志及增量日志，并且不断写入MongoDB：
2.2.双写
在进行了同步操作之后，此时MongoDB中数据已经几乎和MySQL一致，但是此时并不能直接将读写操作切换到MongoDB中，因为在切换的这个过程中会出现数据不一致，此时就需要双写。
所谓双写其实就是在程序中写入MySQL时，也将这份数据转换格式并同时写入MongoDB，为了不影响接口写入的pct99时间，可以将对MongoDB的写入进行异步化，对于写入失败的数据再定时回捞写入。
注意由于Binlog监听程序也在进行数据增量写入，所以可以通过开关控制双写启动后，关闭Binlog监听程序。
2.3.校验
经过同步及双写两个步骤，此时MySQL和MongoDB应该已经保持线上实时同步了，但是为了确保双写的数据不出问题，需要通过定时任务来对MySQL及MongoDB的数据一致性做抽样校验，当校验到数据不一致时，以MySQL的数据为准覆盖MongoDB中的对应数据。
2.4.切读
当抽样校验持续一段时间（如一周）时，如果数据一致性基本为100%时，可以启动切读。
所谓切读指的是将数据读取时，不对MySQL进行读取，而是对MongoDB进行读取。此时通过灰度控制来进行小流量数据读取，在观察一段时间没问题后，逐步放大切读流量，直到100%读MongoDB。
2.5.切写
切读完成后，读取时就已经不依赖于老MySQL，而是依赖于新MongoDB了。此时要做的最后一步是切写，也就是关闭双写，只写MongoDB。此时数据迁移完成，读写均通过MongoDB。
3.切量过程关键点
数据校验以最终结果量为准，因为过程量可能不置信，最好可以实现切读后的数据打点趋势与原流程趋势做对比产出报告
切量过程必须是可以回滚的，并且需要小流量的切量观察。
————————其他参考——————————————————
一、迁移过程需要满足的目标
- 迁移应该是在线的迁移，也就是在迁移的同时还会有数据的写入；
- 数据应该保证完整性，也就是说在迁移之后需要保证新的库和旧的库的数据是一致的；
- 迁移的过程需要做到可以回滚，这样一旦迁移的过程中出现问题，可以立刻回滚到源库不会对系统的可用性造成影响。
如果你使用 Binlog 同步的方式，在同步完成后再修改代码，将主库修改为新的数据库，这样就不满足可回滚的要求，一旦迁移后发现问题，由于已经有增量的数据写入了新库而没有写入旧库，不可能再将数据库改成旧库。
二、同步双写
2.1 步骤
1.将新的库配置为源库的从库用来同步数据；如果需要将数据同步到多库多表，那么可以使用一些第三方工具获取 Binlog 的增量日志（比如开源工具 Canal），在获取增量日志之后就可以按照分库分表的逻辑写入到新的库表中了。
2.同时我们需要改造业务代码，在数据写入的时候不仅要写入旧库也要写入新库。当然，基于性能的考虑，我们可以异步地写入新库，只要保证旧库写入成功即可。但是我们需要注意的是，需要将写入新库失败的数据记录在单独的日志中，这样方便后续对这些数据补写，保证新库和旧库的数据一致性。
3.然后我们就可以开始校验数据了。由于数据库中数据量很大，做全量的数据校验不太现实。你可以抽取部分数据，具体数据量依据总体数据量而定，只要保证这些数据是一致的就可以。
- 双写时加开关，默认关闭双写，上线完成后关闭同步，同时打开开关，在低峰期的话数据丢失的概率不高。再配合数据校验的工作，是可以保证一致性的
- 如果一切顺利，我们就可以将读流量切换到新库了。由于担心一次切换全量读流量可能会对系统产生未知的影响，所以这里最好采用灰度的方式来切换，比如开始切换 10% 的流量，如果没有问题再切换到 50% 的流量，最后再切换到 100%。
- 由于有双写的存在，所以在切换的过程中出现任何的问题都可以将读写流量随时切换到旧库去，保障系统的性能。
- 在观察了几天发现数据的迁移没有问题之后，就可以将数据库的双写改造成只写新库，数据的迁移也就完成了。
最容易出现问题
数据校验的工作
建议迁移前写好数据校验的工具或脚本，在测试环境上充分测试之后，在开始正式的数据迁移
三、同步双写升级版 ---- 本地库上云
本地库上云，另外考虑的重要因素 -- 带宽和延迟
尽量减少跨专线的读操作
切换读流量的时候你需要保证自建机房的应用服务器读取本机房的数据库，云上的应用服务器读取云上的数据库。
这样在完成迁移之前，只要将自建机房的应用服务器停掉并且将写入流量都切到新库就可以了。
四、应用场景
无论是迁移 MySQL 中的数据还是迁移 Redis 中的数据，甚至迁移消息队列都可以使用这种方式，你在实际的工作中可以直接拿来使用。
五、优缺点
优点是：迁移的过程可以随时回滚，将迁移的风险降到了最低。
缺点是：时间周期比较长，应用有改造的成本。
六、衍生两种方案
1、基于同步写新库和旧库方案
在写入数据的时候，同步写入旧库数据，异步写入新库数据。
数据校验，对部分数据进行校验（最容易出问题的地方，需要提前准备好脚本）。
使用灰度发布方式将读流量切换到新库。
观察几天没问题后，可以改成只写新库。
2、基于Canal的迁移方案
将新库配置为源库的从库，同步数据。比如使用Canal同步数据。
数据校验，对部分数据进行校验（最容易出问题的地方，需要提前准备好脚本）。
使用灰度发布方式将读流量切换到新库。
暂停应用，将新库作为主库写入，使用Canal同步到旧库。
观察几天没问题后，撤销Canal的同步。
