分库分表后数据如何迁移

一、分库分表后数据如何迁移概述

• 针对单库表中的数据我们如何迁移到新的分库分表上，最先想到的方案应该就是发公告停机停服的数据迁移。

二、停机停服数据迁移的概述

• 比如我们已经准备好某一天要进行数据迁移了，那么我会们在当天发布公告，比如通告一下用户，凌晨12点到早上6点系统升级，服务暂不可用。
• 到了凌晨12点，所有服务停机，并观察数据库中是否还有数据写入变更删除等操作，如果发现现在数据库中的数据已经静止了，那么一部分人负责升级代码，一部分人负责变更新的数据源配置，一部分人利用事先写好的数据迁移脚本，对旧库中的数据进行读取并新增到新的库表中。
• 由于这段时间是停机停服的，所以不会有新的业务数据产生，那么当数据迁移完毕后。启动服务并观察线上环境是否有异常，进行一遍主要流程的测试工作，如果功能无异常，则迁移工作完毕。
• 当然，这种方案很简单，对于一般系统来说，都是可以接收的，毕竟凌晨12点到6点这段时间，用户使用场景很低。
• 但是，依然无法避免的就是，对用户的感受是不好的，毕竟系统无法使用了。那么，我们还有另一种迁移方案，即：双写方案。

三、双写数据迁移的概述

• 针对于停机停服数据迁移的劣势，我们可以在持久层做请求拦截，将写入、修改、删除操作修改为双写，即：对旧库和新库都要做CUD操作。那么，新的数据也就会在新库中存在一份。
• 此时，开启数据迁移工具，将数据新增到新库中。当然，这种迁移不是没有约束的，我们会在根据业务表中的modify_time字段进行约束，即：只有小于某个modify_time的数据才可以进行迁移。
• 当然，这也无法保证新旧库中的数据完全一致，比如就是在数据迁移过程中，有旧的数据没有在新库中，但是被修改了。针对于这种情况，我们会开启第二遍的check操作，将第一遍数据迁移后的新旧库中数据再进行校验和补充修复。最终达到一致性。