数据迁移的套路

URML 2020-05-04

数据迁移的类型

随着业务的发展,存储也会经常性的需要迁移。以下场景是我们开发过程中经常遇到的

  1. 业务、团队在快速扩张,需要适当时机进行微服务的拆分,需要独立的数据库,将数据从源数据库迁移到新的数据库
  2. 单表的记录数比较大,需要进行分库分表。需要将老表的数据迁移到新的分表中。
  3. 存储选型不对,比如关系型数据库的相互迁移, PG, MySQL,Oracle的相互迁移。NoSQL的Mongo,Cassandra,Hbase的相互迁移。
  4. 机房的迁移,自建机房到云的相互迁移

这些场景都需要进行数据迁移,虽然细节的方案有不同之处,但是也会有一些共同之处。

数据迁移的方案

数据迁移简单来说就是将数据从一个地方挪到另外一个地方。
数据迁移的套路
因为我们的数据不是静态的,所以我们不能随便写个job迁移就好了。需要确保一些迁移上的标准

标准

数据一致性
迁移完数据不能丢记录,单条记录的数据不能缺字段。

不停机
数据在不断的写入,不能为了阻止写入,而不允许数据写入,需要保证业务写入的可用性。

迁移过程可中断、可回滚
这点要求很高,是确保数据万无一失的策略。在迁移数据的各个阶段发现有问题,都可以回滚到原来的库,保证业务正常运行。

迁移方案

数据迁移的套路

为了达到上述要求,一般采用双写策略。也就是写两份,既往老的写,也往新的写。

  1. 收敛读写
    读写的入口越多,后续需要进行开关切换的地方就越多,就越容易出错,所以要尽可能的先将所有的读写入口都收敛到一个地方
  2. 双写
    将增量的数据同时写入到两个存储系统。确保新的写入代码没问题。双写以写入老的为准,老的写入成功代表操作成功了,写入新的失败了需要记录失败日志,分析为何失败,进行修正和补偿
  3. 将老的存量数据迁移过来
    老的存量数据迁移就是通过遍历id,写入新的存储。具体的方案有很多。可以使用同步工具,比如binlog +flink来处理。数据量比较少的就直接遍历就行。
  4. 数据校验
    数据的一致性校验是重中之重,确保两边数据的记录数,单条记录的数据完整性。如果数据量不多,一般是全量校验。数据量很多,可以抽样校验。
  5. 切换新的读
    数据校验通过后,就可以切换到新的读,万一还有问题,可以切换到老的读。排查问题,重新来过。
  6. 停止双写
    在新的存储中安全平稳的运行了N天后,就可以停掉老的读了,整个迁移过程完成了。

注意事项

  1. 对于后端服务,存储是基石,是重中之重。稳定性要求是最高的。一定要确保数据是平滑迁移的,对业务无感知。
  2. 同时存储是有状态的,迁移难度比较大,开发者需要具备前瞻性,尽量在选型的时候慎重,选择合适的数据库,避免进行数据库迁移。发现数据库选型有潜在的问题时,需要当机立断,尽早迁移。不要以为出现问题的概率不大,就拖延了。否则一旦出现问题,就是重大故障,造成的损失难以估量。

相关推荐