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

目录

一 老库表写收口

二 平滑迁移数据

三 业务影响最小

四 增量数据回写

五 迁移回滚方案

六 业务流量灰度

七 如何进行测试

八 老库下线

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

---

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

一 老库表写收口

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

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

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

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

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

二 平滑迁移数据

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

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