1: 背景
公司之前有一个非常老的系统，需要进行重构，包括代码的重构，还有数据库的迁移，目前难点就是在于数据库的数据迁移了，因为当前app一直有用户使用的，如果停机的话，会严重影响用户体验，停机方案是直接被否决的，本次使用的是不停机的数据库迁移。
2：迁移的方案
不停机的数据库迁移方案，主要包括以下步骤
1: 先利用myqsldump文件，把之前的数据全部迁移过来
2: 通过update_time字段，把迁移过程中的新增的数据迁移过来
3: 开启双写， 先写源表数据，再写目标表数据
4：数据库的增量数据的对比和校验，以源表为准
5: 稳定一段时间后，切换写数据顺序，先写目标表，再写源表
6：数据库的增量数据的对比和校验，以目标表为准
7: 稳定一段时间后，读写完全用目标表，源表下线，完成迁移
3: 迁移的问题
3.1: 怎么提高mysqldump的导入数据？
1：设置写binlog的参数为0，即每次提交数据不写binlog, 等系统自己刷新binlog
2: 设置写redlog的参数为0， 即每次提交数据不写redlog, 等系统自己刷新redlog
3.2: 双写怎么实现？
1： 第一种方案，在每一处调用update和insert的地方，加上双写逻辑，这样的实现方式最简单，但是怕改漏
2： 第二种方案，Aop方案，在表的写逻辑处使用AOP，AOP内部的逻辑就是双写，改造的范围小，不怕漏
3.3: 如果源表写入成功，但是写目标表失败呢？
没有关系，后续有检验增量定时任务，会补全的，这种当初设计的时候，也是新增了日志告警，可以及时发现写入目标表失败的细节，后面人工注意观察
3.4: 目标表的主键怎么设计的？
目标表主键是同步源表的，先写源表，写入成功了，源表会返回主键，后续写目标表的直接用该主键就可以了，这样可以防止数据不一致的问题
3.5: 定时任务检验增量数据是怎么做的？
1：第一种方案是最简单的，我们表有update_time字段，通过update_time查询出某一段时间的数据，去对比源表和目标表关键性字段，如果不一致就更新。
2：第二种方案，也是我们采用的方案，通过消费源表的binlog，当源表binlog是写数据的时候，我们会通过binlog的信息查询源表和目标表数据，进行对比。
3.6: 对比数据是查询从库还是主库？
为了缓解主库的压力，其实我们查询的是从库，但是从库可能会有主库延迟的问题，所以当查询源表和目标数据不一致的时候，我们才再去查主库，其实不一致的情况不多，这样就能解决主库压力过大的问题。