如何平滑的迁移数据库中的数据
简单的实现方案：
- 通过 MySQL 主从同步的方式做到准实时的数据拷贝
- 通过 mysqldump 工具将源库的数据导出再导入到新库
存在的问题：
- 这两种方式只能支持单库到单库的迁移，无法支持单库到多库多表的场景
- 迁移的同时还有数据写入
平滑迁移需要满足的条件：
- 迁移应该是在线的迁移，也就是在迁移的同时还会有数据的写入；
- 数据应该保证完整性，也就是说在迁移之后需要保证新的库和旧的库的数据是一致的；
- 迁移的过程需要做到可以回滚，这样一旦迁移的过程中出现问题，可以立刻回滚到源库不会对系统的可用性造成影响
一般来说，我们有两种方案可以做数据库的迁移
- 双写
- 级联同步
双写
-
将新的库配置为源库的从库用来同步数据；如果需要将数据同步到多库多表，那么可以使用一些第三方工具获取 Binlog 的增量日志（比如开源工具 Canal），在获取增量日志之后就可以按照分库分表的逻辑写入到新的库表中了
-
同时我们需要改造业务代码，在数据写入的时候不仅要写入旧库也要写入新库。当然，基于性能的考虑，我们可以异步地写入新库，只要保证旧库写入成功即可。但是我们需要注意的是，需要将写入新库失败的数据记录在单独的日志中，这样方便后续对这些数据补写，保证新库和旧库的数据一致性
-
然后就可以开始校验数据了。由于数据库中数据量很大，做全量的数据校验不太现实。你可以抽取部分数据，具体数据量依据总体数据量而定，只要保证这些数据是一致的就可以
-
如果一切顺利，我们就可以将读流量切换到新库了。由于担心一次切换全量读流量可能会对系统产生未知的影响，所以这里最好采用灰度的方式来切换，比如开始切换 10% 的流量，如果没有问题再切换到 50% 的流量，最后再切换到 100%
-
由于有双写的存在，所以在切换的过程中出现任何的问题都可以将读写流量随时切换到旧库去，保障系统的性能
-
在观察了几天发现数据的迁移没有问题之后，就可以将数据库的双写改造成只写新库，数据的迁移也就完成了
级联同步方案
比较适合数据从自建机房向云上迁移的场景
在自建机房准备一个备库，在云上环境上准备一个新库，通过级联同步的方式在自建机房留下一个可回滚的数据库
- 先将新库配置为旧库的从库，用作数据同步；
- 再将一个备库配置为新库的从库，用作数据的备份
- 等到三个库的写入一致后，将数据库的读流量切换到新库
- 然后暂停应用的写入，将业务的写入流量切换到新库（由于这里需要暂停应用的写入，所以需要安排在业务的低峰期）
回滚方案：
方案的回滚方案也比较简单，可以先将读流量切换到备库再暂停应用的写入，将写流量切换到备库，这样所有的流量都切换到了备库，也就是又回到了自建机房的环境
数据迁移时如何预热缓存
缓存迁移的重点是保持缓存的热度
Redis 的数据迁移可以使用双写的方案或者级联同步的方案
