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

思维导图

思维导图.png

---

系列总目录

• 业务场景实战汇总

---

背景

• 数据迁移到新表
• 分库分表
• 迁移考验的不是一个人的技术功底，而是一个人干活的细致程度，以及抗压能力
• 数据迁移必定涉及一个全量和增量的数据，如何保证数据不会重复，不会丢失
• 使用的是阿里的DTS: 会在全量任务的时候相当于记录数据库的一个副本，然后增量的时候对于已经存在的记录可以进行更新操作。如果是delete语句，一般是要求软删，真遇到delete，需要进一步业务方验证，比如业务方记录日志表，通过表判断
• 如果只是数据库迁移，又有双写，并且切流一部分写新库。这时候需要将新库的主键id步长加大，以至于旧表迁移过来不至于主键冲突。但如果是分表方案需要对写新表的id进行手动处理

---

具体步骤

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保证有序，消费时有序

---

双向同步

• 比如在异地多活时，两个集群同时对外提供数据吗，又需要双向冗余数据库
• 数据库的双主双写并双向同步场景，主要考虑数据完整性、一致性和避免冲突。对于同一个库，同一张表，同一个记录中的同一字段的两地变更，会引发数据一致性判断冲突，尽可能通过业务场景设计规避，比如A区用奇数，B区用偶数id
• 双向同步潜在可能引发循环同步的问题，需要做回环控制

• 可以考虑一种通用的标记 SQL 方案。简单来说，就是在同步复制入库时插入特殊的标记 SQL 语句来标记这是来自复制程序的变更，这个标记 SQL 会进入 binlog 中。而在复制程序读取时，通过识别这个标记 SQL 来过滤判断。binlog 中存储了对数据产生变更影响的的 SQL 语句

  
  
  binlog事务.png

• 如下只有第 5 种情况，一个事务被拆成 3 段来同步。中间一段因为没有事务头和尾的标记，复制程序读取时将无法判断，导致循环同步，需要避免。通过把复制程序的批量读取范围固定设置为至少大于或等于写入的事务长度范围，避免了第 5 种情况

  
  
  事务拆分.png
• 还有中方案是使用: GTID(全局事务ID), 生成GTID时使用自己设置的gtid, 由于我们显示指定了GTID，目标库就会使用这个GTID当做当前事务ID，不会自动生成。这个操作也会在目标库产生binlog信息，需要同步回源库。再往源库同步时，我们按照相同的方式，先设置GTID，在执行解析binlog后得到的SQL，还是上面的内容就会被忽略，对于一条没有主键或者唯一索引的记录，即使重复插入也没有，只要GTID已经执行过，之后的重复插入都会忽略，这种方案比辅助表更轻量，但是辅助表可以添加更多信息

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

---

参考文章

• 菜鸟积分系统稳定性建设 - 分库分表&百亿级数据迁移
• 聊聊知乎订单系统迁移
• mysql数据库双向同步复制