数据库迁移实践

1: 背景

公司之前有一个非常老的系统,需要进行重构,包括代码的重构,还有数据库的迁移,目前难点就是在于数据库的数据迁移了,因为当前app一直有用户使用的,如果停机的话,会严重影响用户体验,停机方案是直接被否决的,本次使用的是不停机的数据库迁移。

2:迁移的方案

不停机的数据库迁移方案,主要包括以下步骤

1: 先利用myqsldump文件,把之前的数据全部迁移过来

2: 通过update_time字段,把迁移过程中的新增的数据迁移过来

3: 开启双写, 先写源表数据,再写目标表数据

4:数据库的增量数据的对比和校验,以源表为准

5: 稳定一段时间后,切换写数据顺序,先写目标表,再写源表

6:数据库的增量数据的对比和校验,以目标表为准

7: 稳定一段时间后,读写完全用目标表,源表下线,完成迁移

3: 迁移的问题

3.1: 怎么提高mysqldump的导入数据?

1:设置写binlog的参数为0,即每次提交数据不写binlog, 等系统自己刷新binlog

2: 设置写redlog的参数为0, 即每次提交数据不写redlog, 等系统自己刷新redlog

3.2: 双写怎么实现?

1: 第一种方案,在每一处调用update和insert的地方,加上双写逻辑,这样的实现方式最简单,但是怕改漏

2: 第二种方案,Aop方案,在表的写逻辑处使用AOP,AOP内部的逻辑就是双写,改造的范围小,不怕漏

3.3: 如果源表写入成功,但是写目标表失败呢?

没有关系,后续有检验增量定时任务,会补全的,这种当初设计的时候,也是新增了日志告警,可以及时发现写入目标表失败的细节,后面人工注意观察

3.4: 目标表的主键怎么设计的?

目标表主键是同步源表的,先写源表,写入成功了,源表会返回主键,后续写目标表的直接用该主键就可以了,这样可以防止数据不一致的问题

3.5: 定时任务检验增量数据是怎么做的?

1:第一种方案是最简单的,我们表有update_time字段,通过update_time查询出某一段时间的数据,去对比源表和目标表关键性字段,如果不一致就更新。

2:第二种方案,也是我们采用的方案,通过消费源表的binlog,当源表binlog是写数据的时候,我们会通过binlog的信息查询源表和目标表数据,进行对比。

3.6: 对比数据是查询从库还是主库?

为了缓解主库的压力,其实我们查询的是从库,但是从库可能会有主库延迟的问题,所以当查询源表和目标数据不一致的时候,我们才再去查主库,其实不一致的情况不多,这样就能解决主库压力过大的问题。

相关推荐
现在就干19 分钟前
Spring事务基础:你在入门时踩过的所有坑
java·后端
该用户已不存在31 分钟前
Gradle vs. Maven,Java 构建工具该用哪个?
java·后端·maven
JohnYan42 分钟前
Bun技术评估 - 23 Glob
javascript·后端·bun
二闹1 小时前
聊天怕被老板发现?摩斯密码来帮你
后端·python
用户298698530141 小时前
# C#:删除 Word 中的页眉或页脚
后端
David爱编程1 小时前
happens-before 规则详解:JMM 中的有序性保障
java·后端
小张学习之旅1 小时前
ConcurrentHashMap
java·后端
PetterHillWater1 小时前
阿里Qoder的Quest小试牛刀
后端·aigc
程序猿阿伟2 小时前
《支付回调状态异常的溯源与架构级修复》
后端·架构
dreams_dream2 小时前
django错误记录
后端·python·django