MySQL 亿级数据平滑迁移实战(来自vivo)
https://www.cnblogs.com/vivotech/p/18373623
1、方案选型
常见的迁移方案大致可以分为以下几类:
而预约业务有以下特点:
- 读写场景多,频率高,在用户预约/取消预约/福利发放等场景均涉及到大量的读写。
- 不可接受停机,停机不可避免的会造成经济损失,在有其他方案的情况下不适合选择此方案。
- 大部分的场景能接受秒级的数据不一致,少部分不能。
结合这些特点,我们再评估下上面的方案:
停机迁移方案需要停机,不适用于预约场景。
预约场景存在不活跃的用户数据,如果用渐进式迁移方案的话很难迁移干净,可能还需要再写一个迁移任务来辅助完成迁移。
双写方案最大的优势在于每一步操作都可向上回滚,能尽可能的保证业务不出问题。
因此,最终选择的是双写方案。预约业务涉及到的读写场景多,每一个场景单独进行改造的成本大,采用 Mybatis 插件来实现迁移所需的双写等功能,可以有效降低改造成本。
2、前期准备
// 全量同步基于 MySQLDump 实现;增量同步基于 binlog 实现;一致性校验通过在新老库各选一个分块,然后聚合列数据计算并对比其特征值实现。标签:方案,场景,预约,数据库,停机,迁移,数据,双写 From: https://www.cnblogs.com/clarino/p/18433018