回滚方案
可先将读流量切换到备库，再暂停应用的写入，将写流量切换到备库，这样所有流量都切到了备库，即又回到自建机房环境，就可认为已回滚了。
级联迁移方案可应用在将MySQL、Redis从自建机房迁移到云上的场景。
缺点
在切写的时候需要短暂的停止写入，对于业务来说是有损的，不过如果在业务低峰期来执行切写，可以将对业务的影响降至最低。
数据迁移时如何预热缓存
从自建机房向云上迁移数据时，也要考虑缓存的迁移方案。
缓存本来就是作为一个中间的存储而存在的，我只需在云上部署一个空的缓存节点，云上请求也会穿透到云上数据库，然后回种缓存，对于业务没有影响。
但还要考虑缓存命中率。
如部署空缓存，那所有请求都穿透到DB，DB可能宕机，这样你的服务不可用了。所以，缓存迁移重点是保持缓存热度。
Redis数据迁移可使用双写或级联同步方案，所以这里就不考虑Redis缓存的同步了，而以Memcached为例说明。
使用副本组预热缓存
为保证缓存可用性，可部署多个副本组尽量将请求阻挡在DB层之上。
数据的:
- 写入流程，写入Master、Slave和所有的副本组
- 读取数据时，先读副本组数据，若读取不到，再到Master和Slave加载数据，再写入到副本组
那么，我们就能在云上部署一个副本组，这样，云上应用服务器读取云上副本组，若副本组未查到数据，即可从自建机房部署的主从缓存上加载数据，回种到云上的副本组上。
- 副本组迁移方案示意图
当云上部署的副本组足够热后，即缓存命中率达到至少90%，就能将云机房上的缓存服务器的主从都指向该副本组，迁移完成。
这种方式够简单，但致命问题：若云上请求穿透云上副本组，到达自建机房的主从缓存时，这个过程需要跨越专线。
这不仅会占用大量专线带宽，同时专线延迟相比于缓存的读取时间是比较大的，即使是本地不同机房之间的延迟，也会达到2～3ms，则一次前端请求可能会访问十几次甚至几十次缓存，一次请求就会平白增加几十ms甚至过百ms延迟，极大影响接口响应时间，因此在实际项目中很少用这种方案。
但是这种方案给了思路，可以通过方案的设计在系统运行中自动完成缓存预热，所以改造副本组方案，尽量减少专线带宽占用。
改造副本组方案预热缓存
改造对读写缓存的方式：
- 在云上部署多组mc的副本组，自建机房在接收到写入请求时，会优先写入自建机房的缓存节点，异步写入云上部署的mc节点
- 在处理自建机房的读请求时，会指定一定的流量（比如10%）优先走云上的缓存节点，这样虽然也会走专线穿透回自建机房的缓存节点，但是流量是可控的
- 当云上缓存节点的命中率达到90%以上时，就可以在云上部署应用服务器，让云上的应用服务器完全走云上的缓存节点即可
- 这就能实现缓存数据的迁移，又可尽量控制专线的带宽和请求的延迟情况，可直接在项目使用。
总结
双写是DB、Redis迁移的通用方案，可直接使用。双写方案中最重要的，是通过数据校验保证数据一致性，这就能在迁移过程中随时回滚。
数据库的迁移，则数据校验应该是最需花时间解决的。
若需要将自建机房的数据迁移到云，也可考虑级联复制，会造成数据短暂停写，需在业务低峰期执行。
缓存迁移重点是保证云上缓存的命中率，你可以使用改进版的副本组方式来迁移，在缓存写入的时候异步写入云上的副本组，在读取时放少量流量到云上副本组，从而又可以迁移部分数据到云上副本组，又能尽量减少穿透给自建机房造成专线延迟。
若是自建机房迁移到云上，那么专线的带宽一定是你迁移过程中的一个瓶颈点，你需要在迁移之前梳理清楚有哪些调用需要经过专线，占用带宽的情况是怎样的，带宽的延时是否能够满足要求。你的方案中也需要尽量做到在迁移过程中同机房的服务调用同机房的缓存和数据库，尽量减少对于专线带宽资源的占用。
FAQ
这里的迁移是指的旧库迁移到新库，新旧库的表结构基本一样。但如果系统重构后的迁移就很难做了。我以前遇到一个大的系统，整个db里面有几千张表。重构后采用微服务的方式，原来的一个db分成了10多个db，还做了分表。有些原来旧库的表也做了拆分，合并，字段的增加、减少等。旧库表中的有些字段名字都重新命名了。这样的数据迁移都是狗血的数据迁移。整个公司组建一个数据迁移团队，包括开发，架构师，技术总监，dba，运维等几百人，数据校验也基本都是人工校验。耗几个月才完成了数据迁移。而且问题一大推。面对如何奇葩的数据迁移，有什么好方案？
数据的同步可以考虑解析binlog来同步。校验就真的没辙了，我之前经历的大的数据迁移都是已月为单位的。
业务不做改造的话，无论哪种方案，要想新老环境数据一致，都需要短暂的禁写。即使是业务层做改造，按不同的模块双写数据库，同时MySQL新老环境相互同步，但在具体切换的时候，也要考虑主从延迟，从这点来看，其实还是会有一段时间的禁写。
系统升级案例分享
老系统为.Net+SqlServer，新系统是Java+Mysql。
业务由于是直接基于标品二次开发，所以存在新老系统的业务兼容和数据兼容，并不能简单的通过双写就解决问题。
引入kafka和两个数据同步服务，两个服务之间商定共同认可的统一业务消息体，互相实时发送增量消息，并解析对方发送来的消息结合自己的业务入库。
流量在网关层依据某个hander标识字段去分流，用apollo开关可以随时掌控切换的比例。做到随时能进能退。
数据校验：
- 对全量我们采用了业务抽检+总数校验
- 对增量我们才用了T+1后的增长量校验
为了验证新系统的业务准确性，还在网关层做了流量拷贝，响应对比等。
