spring

业务实战场景(十)用户无感知迁移数据

2022-02-16  本文已影响0人  后来丶_a24d

思维导图

思维导图.png

系列总目录


背景


具体步骤

  1. 线上库配置完成
  2. dts新建表的全量任务
  3. 全量迁移完成后开启增量(自动回溯全量开始时间,消息多次消费会进行幂等), 进度可在界面上观察
  4. 全量数据校验,查看数据是否一致
  5. 改造代码预发测试(采集线上流量进行回放,多种case跑一下,切流开关等校验),没问题发布上线
  6. 再次全量进行校验&订正(数据追平)
  7. 打开双写(保证数据实时性)
  8. 低流量节点(凌晨过后)进行灰度切流userId%x,进行验证,逐步流量打开,持续观察
  9. 双写开关切到新库,保证只写新库,完成数据迁移方案
  10. 系统稳定运行一段时间,迁移&双写代码下线,老库进行资源释放

注意点

  1. 对写新库操作需要进行日志埋点
  2. 新库不要求一定写成功(不影响服务,后期不一致数据通过增量任务兜底,幂等可以通过更新时间或者版本确定)
  3. 如果老库和新库都写,最终返回结果是老数据源
  4. 数据源回滚:开启了双写,新数据库中数据不对(新数据源回滚不了)
  5. 开启双写时机:由于已经开启增量,所以对于还没切流前不需要开启双写。在准备进行切库时,开启双写。为什么这里还需要开启双写: 考虑极限情况下,增量同步任务会出现延迟(理论上是秒级)
  6. 全量默认走备库,目标端写入的是主库,无论是全量还是校验都会对源端备库,目标端主库造成压力,所以这里需要注意一下,设置一个读的上线qps,以免对线上服务造成影响
  7. 整个迁移过程应该是先开启数据的增量同步监听,发送到消息队列后暂时不开启消费者消费,待全量数据同步完成后再开启增量消费消费,这样可以避免在做全量数据迁移过程中数据改动引发的数据不一致问题
  8. 顺序性保证: binlog本身有序,dts监听时mq保证有序,消费时有序

双向同步

SET GTID_NEXT= sdffsdfsfasdfsdf:2’
insert into users(name) values("seeger")

参考文章

上一篇下一篇

猜你喜欢

热点阅读