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

目录

一 老库表写收口

二 平滑迁移数据

三 业务影响最小

四 增量数据回写

五 迁移回滚方案

六 老库下线

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

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

一 老库表写收口

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

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

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

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

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

二 平滑迁移数据

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

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

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

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

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

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

三 业务影响最小

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

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

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

四 增量数据回写

为什么要数据回写呢？

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

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

五 迁移回滚方案

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

服务回滚？

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

数据库回滚？

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

六 老库下线

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

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

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

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

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

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

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