目录
本文主要讲解数据从老库迁移到新库过程中遇到的问题，以及针对这些问题给出的解决方案，希望能给你一点点启发或者帮助。
一 老库表写收口
由于多个业务端的多个服务公用一个老库，且多个服务访问老库共用一套密码。
如何确定只有我们对老库的表进行写入呢？
为了排除还有其他业务端服务直连老库，写老库的表，我们给表添加了一个字段，比如是 A，来标识是我们端对表的写入。如果不是我们端对表的写入，该字段应该是空值。
为什么一定需要确定写收口呢？
假设有某个业务端的服务对老库的表进行写入，然后我们进行了数据迁移，那新老数据库的表的数据将不一致，这在业务上面是不能忍受的。
二 平滑迁移数据
我们端这块有4个表，共1亿的数据，需要进行迁移。这块的核心点是：如何解决迁移数据耗时的问题、如何减少表停写时间对业务测影响问题。
一开始我们定的方案是 RD 停写，DBA 通过脚本执行命令，将历史数据从老库直接迁移到新库，整个过程评估预计需要1小时，这将意味着需要停写1小时，然后将这个结果同步给业务方，业务方无法忍受这个结果。
如何解决迁移数据耗时的问题？
我们使用 ALI 的 DTS 对数据进行迁移。DTS 能同步历史数据和增量数据。
历史数据是迁移了，那如何做到平滑呢？
我们这块将新库集群当做老库的从库进行数据同步，当我们这块进行业务停写的时候、且新库和老库的数据一致的时候，DBA 将新库集群中的一台机器升级为主库，其他机器挂载到这个主库，当做这个机器的从库。
三 业务影响最小
数据迁移过程中，如果能做到对业务无感，是最好的。那如何做好对业务影响最小呢？
首先，我们通过业务数据进行分析，找到业务的低谷。在低谷进行数据迁移操作，对业务影响小。
其次，我们是分钟级别的停写，在停写的时候，我们一直是可读的。这个在业务上是可以忍受的。
四 增量数据回写
为什么要数据回写呢？
在迁移数据的过程中，由于一些团队排期问题，服务读取的还是老库，这个时候为了保证其他团队能读取到增量数据，保证业务不受影响，我们这块通过 Databus 对数据进行了同步，回写到老库。
当然了，我们的期望是只维护新库，所以我们要求其他业务端对读收口进行了排期，2个月之后其他业务端都走我们的接口，实现了读收口。
五 迁移回滚方案
回滚方案在数据迁移过程中不一定需要，但是从一件事情的完整度来说，还是需要的。针对这块数据迁移，我们需要考虑的是服务回滚、数据库回滚。
服务回滚？
是说服务从读新库切换到读老库，这块可以做一个数据源动态开关，可以灵活切换访问新老数据源。
数据库回滚？
如果是增量数据我们需要将它们从新库同步到老库，保证数据的完整性。
六 老库下线
数据迁移完了就完了？不，我们还需要下线老库。
从公司资产角度考虑，有了新库，为了降低成本，我们需要将老库下线。
从一件事情完整性来看，我们迁移数据只是完成了90%，剩下的10% 我们需要对老库进行下线处理。
七 事前、事中、事后、我们应该做什么呢
事前：我们应该给公司的研发和业务发送邮件，邮件的主题、涉及范围、影响功能、数据迁移时间点、负责人、迁移方案、以及钉钉沟通群。
事中：我们研发应该和各个业务端确认方案的可行性、与 DBA、QA 建立紧密的沟通，随时同步方案进度、开发进度、迁移进度。
事后：我们研发应该发邮件告知研发和业务、BI、大数据等团队，已经完成数据库的迁移，及时同步迁移结果。钉钉群里面也需要同步。
