【数据库】生产-数据迁移

MySQL 亿级数据平滑迁移实战(来自vivo)

https://www.cnblogs.com/vivotech/p/18373623

 

1、方案选型

常见的迁移方案大致可以分为以下几类:

image

而预约业务有以下特点:

  • 读写场景多,频率高,在用户预约/取消预约/福利发放等场景均涉及到大量的读写。
  • 不可接受停机,停机不可避免的会造成经济损失,在有其他方案的情况下不适合选择此方案。
  • 大部分的场景能接受秒级的数据不一致,少部分不能。

结合这些特点,我们再评估下上面的方案:

image

停机迁移方案需要停机,不适用于预约场景。

预约场景存在不活跃的用户数据,如果用渐进式迁移方案的话很难迁移干净,可能还需要再写一个迁移任务来辅助完成迁移。

双写方案最大的优势在于每一步操作都可向上回滚,能尽可能的保证业务不出问题。

因此,最终选择的是双写方案。预约业务涉及到的读写场景多,每一个场景单独进行改造的成本大,采用 Mybatis 插件来实现迁移所需的双写等功能,可以有效降低改造成本。

2、前期准备

 // 全量同步基于 MySQLDump 实现;增量同步基于 binlog 实现;一致性校验通过在新老库各选一个分块,然后聚合列数据计算并对比其特征值实现。
 

 

posted @   飞翔在天  阅读(24)  评论(0编辑  收藏  举报
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
历史上的今天:
2023-09-26 【Spring-Integration】Cache抽象
点击右上角即可分享
微信分享提示