数据库迁移实践

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: 对比数据是查询从库还是主库?

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

相关推荐
砌玉成璧几秒前
Flask一个用户同时只能在一处登录实现
后端·python·flask
元闰子8 分钟前
分离还是统一,这是个问题
后端·面试·架构
寻月隐君17 分钟前
Rust Scoped Threads 实战:更安全、更简洁的并发编程
后端·rust·github
爷_1 小时前
手把手教程:用腾讯云新平台搞定专属开发环境,永久免费薅羊毛!
前端·后端·架构
山间小僧1 小时前
「查漏补缺」ZGC相关内容整理
java·jvm·后端
程序视点2 小时前
FDM下载神器:免费多线程下载工具,速度90+M/S,完美替代1DM!
windows·后端
Livingbody2 小时前
【ERNIEKit】基于ERNIE4.5-0.3B大模型微调的心理咨询师大模型全流程
后端
CRUD被占用了3 小时前
coze-studio学习笔记(二)
后端
长安不见3 小时前
图与循环依赖、死锁(一) 为何我的循环依赖时好时坏?
后端