加餐 数据的迁移应该如何做？
你好，我是唐扬。
在“数据库优化方案（二）：写入数据量增加时，如何实现分库分表？”中我曾经提到，由于MySQL不像MongoDB那样支持数据的Auto Sharding（自动分片），所以无论是将MySQL单库拆分成多个数据库，还是由于数据存储的瓶颈，不得不将多个数据库拆分成更多的数据库时你都要考虑如何做数据的迁移。
其实在实际工作中，不只是对数据库拆分时会做数据迁移，很多场景都需要你给出数据迁移的方案，比如说某一天，你的老板想要将应用从自建机房迁移到云上，那么你就要考虑将所有自建机房中的数据，包括MySQL、Redis、消息队列等组件中的数据全部迁移到云上，这无论对哪种规模的公司来说都是一项浩瀚的工程，所以你需要在迁移之前准备完善的迁移方案。
“数据的迁移”的问题比较重要和繁琐，也是开发和运维同学关注的重点。在课程更新的过程中，我看到有很多同学，比如@每天晒白牙，@枫叶11，@撒旦的堕落等等，在留言区询问如何做数据迁移，所以我策划了一期加餐，准备从数据库迁移和缓存迁移两个方面带你掌握数据迁移的方法，也带你了解数据迁移过程中需要注意的关键点，尽量让你避免踩坑。
如何平滑地迁移数据库中的数据
你可能会认为：数据迁移无非是将数据从一个数据库拷贝到另一个数据库，可以通过MySQL 主从同步的方式做到准实时的数据拷贝；也可以通过mysqldump工具将源库的数据导出再导入到新库，这有什么复杂的呢？
其实这两种方式只能支持单库到单库的迁移，无法支持单库到多库多表的场景。而且即便是单库到单库的迁移，迁移过程也需要满足以下几个目标：
- 迁移应该是在线的迁移，也就是在迁移的同时还会有数据的写入；
- 数据应该保证完整性，也就是说在迁移之后需要保证新的库和旧的库的数据是一致的；
- 迁移的过程需要做到可以回滚，这样一旦迁移的过程中出现问题，可以立刻回滚到源库不会对系统的可用性造成影响。
如果你使用Binlog同步的方式，在同步完成后再修改代码，将主库修改为新的数据库，这样就不满足可回滚的要求，一旦迁移后发现问题，由于已经有增量的数据写入了新库而没有写入旧库，不可能再将数据库改成旧库。
一般来说，我们有两种方案可以做数据库的迁移。
“双写”方案
第一种方案我称之为双写，其实说起来也很简单，它可以分为以下几个步骤。
- 将新的库配置为源库的从库用来同步数据；如果需要将数据同步到多库多表，那么可以使用一些第三方工具获取Binlog的增量日志（比如开源工具Canal），在获取增量日志之后就可以按照分库分表的逻辑写入到新的库表中了。
- 同时我们需要改造业务代码，在数据写入的时候不仅要写入旧库也要写入新库。当然，基于性能的考虑，我们可以异步地写入新库，只要保证旧库写入成功即可。但是我们需要注意的是，需要将写入新库失败的数据记录在单独的日志中，这样方便后续对这些数据补写，保证新库和旧库的数据一致性。
- 然后我们就可以开始校验数据了。由于数据库中数据量很大，做全量的数据校验不太现实。你可以抽取部分数据，具体数据量依据总体数据量而定，只要保证这些数据是一致的就可以。
- 如果一切顺利，我们就可以将读流量切换到新库了。由于担心一次切换全量读流量可能会对系统产生未知的影响，所以这里最好采用灰度的方式来切换，比如开始切换10%的流量，如果没有问题再切换到50%的流量，最后再切换到100%。
- 由于有双写的存在，所以在切换的过程中出现任何的问题都可以将读写流量随时切换到旧库去，保障系统的性能。
- 在观察了几天发现数据的迁移没有问题之后，就可以将数据库的双写改造成只写新库，数据的迁移也就完成了。
其中最容易出问题的步骤就是数据校验的工作，所以我建议你在未开始迁移数据之前先写好数据校验的工具或者脚本，在测试环境上测试充分之后，再开始正式的数据迁移。
如果是将数据从自建机房迁移到云上，你也可以使用这个方案，只是你需要考虑的一个重要的因素是：自建机房到云上的专线的带宽和延迟，你需要尽量减少跨专线的读操作，所以在切换读流量的时候你需要保证自建机房的应用服务器读取本机房的数据库，云上的应用服务器读取云上的数据库。这样在完成迁移之前，只要将自建机房的应用服务器停掉并且将写入流量都切到新库就可以了。
这种方案是一种比较通用的方案，无论是迁移MySQL中的数据还是迁移Redis中的数据，甚至迁移消息队列都可以使用这种方式，你在实际的工作中可以直接拿来使用。
这种方式的好处是：迁移的过程可以随时回滚，将迁移的风险降到了最低。劣势是：时间周期比较长，应用有改造的成本。
级联同步方案
这种方案也比较简单，比较适合数据从自建机房向云上迁移的场景。因为迁移上云最担心云上的环境和自建机房的环境不一致，会导致数据库在云上运行时因为参数配置或者硬件环境不同出现问题。
所以我们会在自建机房准备一个备库，在云上环境上准备一个新库，通过级联同步的方式在自建机房留下一个可回滚的数据库，具体的步骤如下：
- 先将新库配置为旧库的从库，用作数据同步；
- 再将一个备库配置为新库的从库，用作数据的备份；
- 等到三个库的写入一致后，将数据库的读流量切换到新库；
- 然后暂停应用的写入，将业务的写入流量切换到新库（由于这里需要暂停应用的写入，所以需要安排在业务的低峰期）。
这种方案的回滚方案也比较简单，可以先将读流量切换到备库再暂停应用的写入，将写流量切换到备库，这样所有的流量都切换到了备库，也就是又回到了自建机房的环境，就可以认为已经回滚了。
上面的级联迁移方案可以应用在将MySQL从自建机房迁移到云上的场景，也可以应用在将Redis从自建机房迁移到云上的场景，如果你有类似的需求可以直接拿来应用。
这种方案优势是简单易实施，在业务上基本没有改造的成本；缺点是在切写的时候需要短暂的停止写入，对于业务来说是有损的，不过如果在业务低峰期来执行切写，可以将对业务的影响降至最低。
数据迁移时如何预热缓存
另外，在从自建机房向云上迁移数据时，我们也需要考虑缓存的迁移方案是怎样的。那么你可能会说：缓存本来就是作为一个中间的存储而存在的，我只需要在云上部署一个空的缓存节点，云上的请求也会穿透到云上的数据库，然后回种缓存，对于业务是没有影响的。
你说得没错，但是你还需要考虑的是缓存的命中率。
如果你部署一个空的缓存，那么所有的请求就都穿透到数据库，数据库可能因为承受不了这么大的压力而宕机，这样你的服务就会不可用了。所以，缓存迁移的重点是保持缓存的热度。
刚刚我提到，Redis的数据迁移可以使用双写的方案或者级联同步的方案，所以在这里我就不考虑Redis缓存的同步了，而是以Memcached为例来说明。
使用副本组预热缓存
在“缓存的使用姿势（二）：缓存如何做到高可用？”中，我曾经提到为了保证缓存的可用性，我们可以部署多个副本组来尽量将请求阻挡在数据库层之上。
数据的写入流程是写入Master、Slave和所有的副本组，而在读取数据的时候，会先读副本组的数据，如果读取不到再到Master和Slave里面加载数据，再写入到副本组中。那么，我们就可以在云上部署一个副本组，这样，云上的应用服务器读取云上的副本组，如果副本组没有查询到数据，就可以从自建机房部署的主从缓存上加载数据，回种到云上的副本组上。
当云上部署的副本组足够热之后，也就是缓存的命中率达到至少90%，就可以将云机房上的缓存服务器的主从都指向这个副本组，这时迁移也就完成了。
这种方式足够简单，不过有一个致命的问题是：如果云上的请求穿透云上的副本组，到达自建机房的主从缓存时，这个过程是需要跨越专线的。
这不仅会占用较多专线的带宽，同时专线的延迟相比于缓存的读取时间是比较大的，即使是本地的不同机房之间的延迟也会达到2ms～3ms，那么一次前端请求可能会访问十几次甚至几十次的缓存，一次请求就会平白增加几十毫秒甚至过百毫秒的延迟，会极大地影响接口的响应时间，因此在实际项目中我们很少使用这种方案。
但是这种方案给了我们思路，让我们可以通过方案的设计在系统运行中自动完成缓存的预热，所以我们对副本组的方案做了一些改造，以尽量减少对专线带宽的占用。
改造副本组方案预热缓存
改造后的方案对读写缓存的方式进行改造，步骤是这样的：
- 在云上部署多组mc的副本组，自建机房在接收到写入请求时，会优先写入自建机房的缓存节点，异步写入云上部署的mc节点；
- 在处理自建机房的读请求时，会指定一定的流量（比如10%）优先走云上的缓存节点，这样虽然也会走专线穿透回自建机房的缓存节点，但是流量是可控的；
- 当云上缓存节点的命中率达到90%以上时，就可以在云上部署应用服务器，让云上的应用服务器完全走云上的缓存节点就可以了。
使用了这种方式，我们可以实现缓存数据的迁移，又可以尽量控制专线的带宽和请求的延迟情况，你也可以直接在项目中使用。
课程小结
以上我提到的数据迁移的方案，都是我在实际项目中经常用到的、经受过实战考验的方案，希望你能通过这节课的学习，将这些方案运用到你的项目中解决实际的问题。与此同时，我想再次跟你强调一下本节课的重点内容：
- 双写的方案是数据库、Redis迁移的通用方案，你可以在实际工作中直接加以使用。双写方案中最重要的，是通过数据校验来保证数据的一致性，这样就可以在迁移过程中随时回滚；
- 如果你需要将自建机房的数据迁移到云上，那么也可以考虑使用级联复制的方案，这种方案会造成数据的短暂停写，需要在业务低峰期执行；
- 缓存的迁移重点是保证云上缓存的命中率，你可以使用改进版的副本组方式来迁移，在缓存写入的时候异步写入云上的副本组，在读取时放少量流量到云上副本组，从而又可以迁移部分数据到云上副本组，又能尽量减少穿透给自建机房造成专线延迟的问题。
如果你作为项目的负责人，那么在迁移的过程中，你一定要制定周密的计划：如果是数据库的迁移，那么数据的校验应该是你最需要花费时间来解决的问题。
如果是自建机房迁移到云上，那么专线的带宽一定是你迁移过程中的一个瓶颈点，你需要在迁移之前梳理清楚有哪些调用需要经过专线，占用带宽的情况是怎样的，带宽的延时是否能够满足要求。你的方案中也需要尽量做到在迁移过程中同机房的服务调用同机房的缓存和数据库，尽量减少对于专线带宽资源的占用。
一课一思
结合实际工作的经验，你可以和我分享一下在做数据迁移的时候都采用了哪些方案吗？这些方案你觉得它的优势和劣势分别是什么呢？
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。
- Geek_zbvt62 👍（32） 💬（4）
a. @_CountingStars的问题提到“双写”方案中主从同步和双写冲突的问题，的回答是双写之前要将同步断掉。 假设我们在夜间进行操作，不考虑主从延迟过高的情况。 但是，”断掉同步“与”有双写代码的应用，被部署上线能正常执行双写“这两个操作之间，时机也不会配合特别完美吧？ 如果先断掉同步，就意味着有可能从库丢掉部分数据。 如果先上线新代码，就意味着短时间内数据要么冲突，要么对于不幂等的操作，数据变成双份了？ b.双写方案的一种隐患是新旧二库在遇到同一资源的并发操作时，执行顺序有可能不一样，进而结果就不一样。这种情况在实践中还要考虑么？ c.另外我还疑问，现代的应用部署都是基于灰度的，在写操作的代码发生切换时（从双写到写新库，或者从写旧库到写新库），做灰度发布都会带来问题吧？
2019-10-25 - mgxian 👍（14） 💬（5）
双写方案中 由于新库配置为旧库的从库 此时双写肯定会出现数据重复的问题啊 或者 数据写入失败
2019-10-25 - 星空 👍（13） 💬（1）
老师说的方案，和我们前几个月做的方案整体上很想。不过我们的方案和场景更复杂一点，我们是系统升级。老系统为.Net+SqlServer，新系统是Java+Mysql。业务上由于是直接基于标品二次开发，所以存在新老系统的业务兼容和数据兼容，并不能简单的通过双写就解决问题。我们引入了kafka组件。和两个数据同步服务，两个服务之间商定共同认可的统一业务消息体，互相实时发送增量消息，并解析对方发送来的消息结合自己的业务入库。流量在网关层依据某个hander标识字段去分流，用apollo开关可以随时掌控切换的比例。做到随时能进能退。数据校验，对全量我们采用了业务抽检+总数校验。对增量我们才用了T+1后的增长量校验。为了验证新系统的业务准确性，还在网关层做了流量拷贝，响应对比等
2019-12-09 - 小喵喵 👍（11） 💬（3）
老师说的迁移是指的旧库迁移到新库，新旧库的表结构基本一样。但是如果系统重构后的迁移就很难做了。我以前遇到一个大的系统，整个db里面有几千张表。重构后采用微服务的方式，原来的一个db分成了10多个db，还做了分表。有些原来旧库的表也做了拆分，合并，字段的增加、减少等。旧库表中的有些字段名字都重新命名了。这样的数据迁移都是狗血的数据迁移。整个公司组建一个数据迁移团队，包括开发，架构师，技术总监，dba，运维等几百人，数据校验也基本都是人工校验。耗几个月才完成了数据迁移。而且问题一大推。面对如何奇葩的数据迁移，老师有什么好的方案？
2019-10-31 - 知行合一 👍（8） 💬（1）
老师，数据具体怎么校验呢，简单说下常用的校验方式吧，谢谢
2019-10-28 - 任鹏斌 👍（5） 💬（1）
老师有个疑问，数据库的双写方案1,2步之间，切换为双写前是不是应该停掉新旧库的同步关系？
2019-11-05 - 钱 👍（4） 💬（1）
数据迁移目前还没做过，不过面试时曾经被问到过，给的是双写的方案。 关键点： 1：数据校验怎么做？ 2：什么时候换成读新库？ 3：什么时候不再写旧库？ 允许停服务，怎么都好说，不能停服务，选择的时机非常关键，那一个时刻判断出数据已经一致了，怎么判断太关键了，线上有可能做不到完全一致，需要做一些线下补偿。 怎么判断数据是否一致呢？记录条数加抽样比对，允许一定的误差，不如总有误差就永远切不了啦！然后再去线下补偿。
2020-04-25 - whiledoing 👍（3） 💬（1）
想问一下老师，如果数据的迁移还伴随着领域模型的重构（库表结构差异巨大，单纯基于binlog主从同步无法达到目标，必须业务上实现数据的模型变更，存量迁移和增量同步双写），有没有一些好的实践经验。
2020-04-14 - Corner 👍（3） 💬（2）
老师您好，关于双写方案有两个疑问需要请教一下。1.数据同时写入两个数据库怎么做对代码的改动比较小呢？有成熟的工具或中间件来做吗？2.新库在同步追上旧库的binlog后，在开始双写时需要断开吗？不然对于新库会有重复的数据。如果新库需要停止对旧库的binlog同步，和双写的开启时机这里怎么做协调呢？
2019-10-25 - 123456 👍（2） 💬（1）
老师，双写需要考虑分布式一致性吗，如何比较简单的实现？
2020-02-19 - 陈斌 👍（2） 💬（1）
老师，想问下双写的具体实现是怎么做呢？我的理解是 1、同步写入旧库和新库，同时需要保证原子性是吗？ 2、是对原本应用服务器中的所有sql语句进行拦截，如果是写操作，则做多一个写入新库的逻辑？
2020-02-08 - la la la 👍（2） 💬（2）
目前正在经历的上云，物理机与云都不互通，需要跳板机一层层的跳，乱七八糟一大堆的东西，就几个人搞，太坑了。
2019-12-02 - 饭团 👍（2） 💬（1）
老师，我有以下疑惑麻烦您解答一下： 1）在双写方式下，因为在切换前必须保证新旧库数据必须完全同步一致，所以这个过程可能会持久很长时间是吧！ 2）在双写情况下，如果是不改变库表结构（就是单库单表还是到单库单表）可以使用主从模式开来同步新的binlog数据！但是如果是存在拆分表是不是执行逻辑就变成了 a：导出旧库binlog，使用chanl应用旧数据到新库！ b：使用Chanl实时同步新的binlog到新库！直到数据完全一致！ 没用过Chanl，不知道是不是这么一个原理！如果不能实时同步binlog那就必然存在停服操作！ 3）在双写模式下，在断掉主从同步，开始双写那一刻。是不是应用修改双写配置，要先于数据库断开主从同步！因为如果反过来，就有可能在那一刻新库丢掉那一刻的数据！
2019-10-25 - helloworld 👍（1） 💬（1）
mysql的binlog是有过期时间的，双写方案中同步binlog的话，也不是全量的binlog，已经存在的全量数据得通过其他的方式迁移到从库中吧？另外关闭双写的时机确实很难把控啊
2020-06-01 - Geek_c42505 👍（1） 💬（1）
请问老师，迁移redis 有分布式锁的存在，该怎样处理好
2020-05-12