数据库迁移遇到的问题和解决方案

目录

一 老库表写收口

二 平滑迁移数据

三 业务影响最小

四 增量数据回写

五 迁移回滚方案

六 老库下线

七 事前、事中、事后、我们应该做什么


本文主要讲解数据从老库迁移到新库过程中遇到的问题,以及针对这些问题给出的解决方案,希望能给你一点点启发或者帮助。

一 老库表写收口

由于多个业务端的多个服务公用一个老库,且多个服务访问老库共用一套密码。

如何确定只有我们对老库的表进行写入呢?

为了排除还有其他业务端服务直连老库,写老库的表,我们给表添加了一个字段,比如是 A,来标识是我们端对表的写入。如果不是我们端对表的写入,该字段应该是空值。

为什么一定需要确定写收口呢

假设有某个业务端的服务对老库的表进行写入,然后我们进行了数据迁移,那新老数据库的表的数据将不一致,这在业务上面是不能忍受的。

二 平滑迁移数据

我们端这块有4个表,共1亿的数据,需要进行迁移。这块的核心点是:如何解决迁移数据耗时的问题、如何减少表停写时间对业务测影响问题。

一开始我们定的方案是 RD 停写,DBA 通过脚本执行命令,将历史数据从老库直接迁移到新库,整个过程评估预计需要1小时,这将意味着需要停写1小时,然后将这个结果同步给业务方,业务方无法忍受这个结果。

如何解决迁移数据耗时的问题?

我们使用 ALI 的 DTS 对数据进行迁移。DTS 能同步历史数据和增量数据。

历史数据是迁移了,那如何做到平滑呢?

我们这块将新库集群当做老库的从库进行数据同步,当我们这块进行业务停写的时候、且新库和老库的数据一致的时候,DBA 将新库集群中的一台机器升级为主库,其他机器挂载到这个主库,当做这个机器的从库。

三 业务影响最小

数据迁移过程中,如果能做到对业务无感,是最好的。那如何做好对业务影响最小呢?

首先,我们通过业务数据进行分析,找到业务的低谷。在低谷进行数据迁移操作,对业务影响小。

其次,我们是分钟级别的停写,在停写的时候,我们一直是可读的。这个在业务上是可以忍受的。

四 增量数据回写

为什么要数据回写呢?

在迁移数据的过程中,由于一些团队排期问题,服务读取的还是老库,这个时候为了保证其他团队能读取到增量数据,保证业务不受影响,我们这块通过 Databus 对数据进行了同步,回写到老库。

当然了,我们的期望是只维护新库,所以我们要求其他业务端对读收口进行了排期,2个月之后其他业务端都走我们的接口,实现了读收口。

五 迁移回滚方案

回滚方案在数据迁移过程中不一定需要,但是从一件事情的完整度来说,还是需要的。针对这块数据迁移,我们需要考虑的是服务回滚、数据库回滚

服务回滚?

是说服务从读新库切换到读老库,这块可以做一个数据源动态开关,可以灵活切换访问新老数据源。

数据库回滚?

如果是增量数据我们需要将它们从新库同步到老库,保证数据的完整性。

六 老库下线

数据迁移完了就完了?不,我们还需要下线老库。

从公司资产角度考虑,有了新库,为了降低成本,我们需要将老库下线。

从一件事情完整性来看,我们迁移数据只是完成了90%,剩下的10% 我们需要对老库进行下线处理。

七 事前、事中、事后、我们应该做什么呢

事前:我们应该给公司的研发和业务发送邮件,邮件的主题、涉及范围、影响功能、数据迁移时间点、负责人、迁移方案、以及钉钉沟通群。

事中:我们研发应该和各个业务端确认方案的可行性、与 DBA、QA 建立紧密的沟通,随时同步方案进度、开发进度、迁移进度。

事后:我们研发应该发邮件告知研发和业务、BI、大数据等团队,已经完成数据库的迁移,及时同步迁移结果。钉钉群里面也需要同步。

评论 10 您还未登录,请先 登录 后发表或查看评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
©️2022 CSDN 皮肤主题:技术黑板 设计师:CSDN官方博客 返回首页

打赏作者

新猿一马

你的鼓励将是我创作的最大动力

¥2 ¥4 ¥6 ¥10 ¥20
输入1-500的整数
余额支付 (余额:-- )
扫码支付
扫码支付:¥2
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值