加餐 | 数据的迁移应该如何做？

Oct 25, 2019

加餐 | 数据的迁移应该如何做？-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

加餐 | 数据的迁移应该如何做？

2019-10-25 唐扬来自北京

《高并发系统设计40问》

课程介绍



讲述：唐扬

时长12:43大小11.64M



你好，我是唐扬。
在“数据库优化方案（二）：写入数据量增加时，如何实现分库分表？”中我曾经提到，由于 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 迁移的通用方案，你可以在实际工作中直接加以使用。双写方案中最重要的，是通过数据校验来保证数据的一致性，这样就可以在迁移过程中随时回滚；
如果你需要将自建机房的数据迁移到云上，那么也可以考虑使用级联复制的方案，这种方案会造成数据的短暂停写，需要在业务低峰期执行；
缓存的迁移重点是保证云上缓存的命中率，你可以使用改进版的副本组方式来迁移，在缓存写入的时候异步写入云上的副本组，在读取时放少量流量到云上副本组，从而又可以迁移部分数据到云上副本组，又能尽量减少穿透给自建机房造成专线延迟的问题。
如果你作为项目的负责人，那么在迁移的过程中，你一定要制定周密的计划：如果是数据库的迁移，那么数据的校验应该是你最需要花费时间来解决的问题。
如果是自建机房迁移到云上，那么专线的带宽一定是你迁移过程中的一个瓶颈点，你需要在迁移之前梳理清楚有哪些调用需要经过专线，占用带宽的情况是怎样的，带宽的延时是否能够满足要求。你的方案中也需要尽量做到在迁移过程中同机房的服务调用同机房的缓存和数据库，尽量减少对于专线带宽资源的占用。
一课一思结合实际工作的经验，你可以和我分享一下在做数据迁移的时候都采用了哪些方案吗？这些方案你觉得它的优势和劣势分别是什么呢？
最后，感谢你的阅读，如果这篇文章让你有所收获，也欢迎你将它分享给更多的朋友。

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 17

提建议

16 | CDN：静态资源如何加速？

17 | 消息队列：秒杀时如何处理每秒上万次的下单请求？

 写留言

精选留言(41)

约书亚
2019-10-25
a. @_CountingStars的问题提到“双写”方案中主从同步和双写冲突的问题，的回答是双写之前要将同步断掉。假设我们在夜间进行操作，不考虑主从延迟过高的情况。但是，”断掉同步“与”有双写代码的应用，被部署上线能正常执行双写“这两个操作之间，时机也不会配合特别完美吧？如果先断掉同步，就意味着有可能从库丢掉部分数据。如果先上线新代码，就意味着短时间内数据要么冲突，要么对于不幂等的操作，数据变成双份了？ b.双写方案的一种隐患是新旧二库在遇到同一资源的并发操作时，执行顺序有可能不一样，进而结果就不一样。这种情况在实践中还要考虑么？ c.另外我还疑问，现代的应用部署都是基于灰度的，在写操作的代码发生切换时（从双写到写新库，或者从写旧库到写新库），做灰度发布都会带来问题吧？
展开
作者回复: 双写时加开关，默认关闭双写，上线完成后关闭同步，同时打开开关，在低峰期的话数据丢失的概率不高。再配合数据校验的工作，是可以保证一致性的
共 4 条评论
31
fomy
2019-11-16
基于双写的方案我总结了2种实现： 1、基于同步写新库和旧库方案在写入数据的时候，同步写入旧库数据，异步写入新库数据。数据校验，对部分数据进行校验（最容易出问题的地方，需要提前准备好脚本）。使用灰度发布方式将读流量切换到新库。观察几天没问题后，可以改成只写新库。 2、基于Canal的迁移方案将新库配置为源库的从库，同步数据。比如使用Canal同步数据。数据校验，对部分数据进行校验（最容易出问题的地方，需要提前准备好脚本）。使用灰度发布方式将读流量切换到新库。暂停应用，将新库作为主库写入，使用Canal同步到旧库。观察几天没问题后，撤销Canal的同步。
展开
14
mgxian
2019-10-25
双写方案中由于新库配置为旧库的从库此时双写肯定会出现数据重复的问题啊或者数据写入失败
作者回复: 双写之前要将同步断掉
共 3 条评论
14
星空
2019-12-09
老师说的方案，和我们前几个月做的方案整体上很想。不过我们的方案和场景更复杂一点，我们是系统升级。老系统为.Net+SqlServer，新系统是Java+Mysql。业务上由于是直接基于标品二次开发，所以存在新老系统的业务兼容和数据兼容，并不能简单的通过双写就解决问题。我们引入了kafka组件。和两个数据同步服务，两个服务之间商定共同认可的统一业务消息体，互相实时发送增量消息，并解析对方发送来的消息结合自己的业务入库。流量在网关层依据某个hander标识字段去分流，用apollo开关可以随时掌控切换的比例。做到随时能进能退。数据校验，对全量我们采用了业务抽检+总数校验。对增量我们才用了T+1后的增长量校验。为了验证新系统的业务准确性，还在网关层做了流量拷贝，响应对比等
展开
作者回复: 这就更复杂了
12
小喵喵
2019-10-31
老师说的迁移是指的旧库迁移到新库，新旧库的表结构基本一样。但是如果系统重构后的迁移就很难做了。我以前遇到一个大的系统，整个db里面有几千张表。重构后采用微服务的方式，原来的一个db分成了10多个db，还做了分表。有些原来旧库的表也做了拆分，合并，字段的增加、减少等。旧库表中的有些字段名字都重新命名了。这样的数据迁移都是狗血的数据迁移。整个公司组建一个数据迁移团队，包括开发，架构师，技术总监，dba，运维等几百人，数据校验也基本都是人工校验。耗几个月才完成了数据迁移。而且问题一大推。面对如何奇葩的数据迁移，老师有什么好的方案？
展开
作者回复: 数据的同步可以考虑解析binlog来同步校验就真的没辙了，我之前经历的大的数据迁移都是已月为单位的
共 3 条评论
9
知行合一
2019-10-28
老师，数据具体怎么校验呢，简单说下常用的校验方式吧，谢谢
作者回复: 比如说从源库随机抽取一定量的数据，从新库中查询看是否一致
8
Victor
2019-10-26
业务不做改造的话，无论哪种方案，要想新老环境数据一致，都需要短暂的禁写。即使是业务层做改造，按不同的模块双写数据库，同时MySQL新老环境相互同步，但在具体切换的时候，也要考虑主从延迟，从这点来看，其实还是会有一段时间的禁写。
7
任鹏斌
2019-11-05
老师有个疑问，数据库的双写方案1,2步之间，切换为双写前是不是应该停掉新旧库的同步关系？
作者回复: 是的，是要先停掉同步关系
4
Corner
2019-10-25
老师您好，关于双写方案有两个疑问需要请教一下。1.数据同时写入两个数据库怎么做对代码的改动比较小呢？有成熟的工具或中间件来做吗？2.新库在同步追上旧库的binlog后，在开始双写时需要断开吗？不然对于新库会有重复的数据。如果新库需要停止对旧库的binlog同步，和双写的开启时机这里怎么做协调呢？
作者回复: 1. 还真没有，其实改动代码也简单 2. 需要断开的，可以在双写的时候加开关，断开同步时立刻打开开关
共 2 条评论
3
钱
2020-04-25
数据迁移目前还没做过，不过面试时曾经被问到过，给的是双写的方案。关键点： 1：数据校验怎么做？ 2：什么时候换成读新库？ 3：什么时候不再写旧库？允许停服务，怎么都好说，不能停服务，选择的时机非常关键，那一个时刻判断出数据已经一致了，怎么判断太关键了，线上有可能做不到完全一致，需要做一些线下补偿。怎么判断数据是否一致呢？记录条数加抽样比对，允许一定的误差，不如总有误差就永远切不了啦！然后再去线下补偿。
展开
作者回复: 数据校验好了就可以切新库
2
torres
2021-03-10
在将本地库迁移到云上库的场景中，为什么需要在本地再建一个云库的备库，然后回滚的时候，切换到这个备库？为什么不直接切换到原来的旧库？
1
Geek_c42505
2020-05-12
请问老师，迁移redis 有分布式锁的存在，该怎样处理好
作者回复: 我会想在业务低峰期迁移
1
whiledoing
2020-04-14
想问一下老师，如果数据的迁移还伴随着领域模型的重构（库表结构差异巨大，单纯基于binlog主从同步无法达到目标，必须业务上实现数据的模型变更，存量迁移和增量同步双写），有没有一些好的实践经验。
作者回复: 先迁移，后重构，不香吗：）如果一起做的话可以基于消息来做，只是会复杂很多
1
ちよくん
2020-01-19
我做过两次数据同步迁移，使用的双写方案，灰度发布，没有问题后全量切，一般需要半个月。
作者回复: 那你们确实比较谨慎：）
1
小水
2019-12-05
老师，应该如何做数据库的切流量呢？是在应用层做个全局的计数吗？然后 10/100，40/100这么切分吗？您在场景用是如何做的呢？
1
la la la
2019-12-02
目前正在经历的上云，物理机与云都不互通，需要跳板机一层层的跳，乱七八糟一大堆的东西，就几个人搞，太坑了。
作者回复: 我目前也在经历上云，物理机和云的互通应该是上云的第一步吧。。
共 2 条评论
1
黎
2019-10-25
有收获
作者回复: 👍
1
徐凌云
2022-06-01
请问下老师，数据库层面咋灰度，如果新库做灰度，新老库增量数据都不一致le
梦楼
2022-03-21
讲的非常好，是我感觉收获最大的一篇了！！！
小胡
2021-08-08
redis的sentinel也可以作为数据迁移方案的一种吧

