数据迁移方案的基本思路为：旧架构继续运行，存量数据直接迁移，增量数据监听binlog，然后通过canal通知迁移程序迁移数据，等到新的数据库拥有全量数据且校验通过后再逐步切换流量到新架构。
数据迁移解决方案的详细步骤如下：
上线canal，通过canal触发增量数据的迁移。
迁移数据脚本测试通过后，将老数据迁移到新的分表分库中。
注意迁移增量数据与迁移老数据的时间差，确保全部数据都被迁移过去，无任何遗漏。
此时新的分表分库中已经拥有全量数据了，可以运行数据验证程序，确保所有数据都存放在新数据库中。
到这里数据迁移就算完成了，之后就是新版本代码上线，至于是灰度上线还是直接上线，需要根据实际情况决定，回滚方案也是一样。
这里的关键点在于，如何保证在导出老数据的快照时，服务不可用的时间最短。
假设：
为了保证高可用，MySQL数据库已经配置了主从复制，因此已经开启了binlog
日常运维工作有执行过数据快照
方案：
先让增量迁移的逻辑运行一会儿，保证从数据库的数据超过了增量迁移的开始点
在一个从节点上dump下来一个快照（从节点也不能长时间的阻塞，尽可能地减少从节点复制中断的时间，至少保证有一个从节点在运行）
将快照导入一个新节点中，在这个新节点中执行分库分表操作
