3.亿级积分数据分库分表：ShardingSphere官方提供的平滑数据迁移方案介绍，有什么缺点呢？

        前面的  2.亿级积分数据分库分表：增量数据同步之代码双写，为什么没用Canal？ 博客中介绍了实现平滑数据迁移的两种方案：Canal监听MySQL的binlog、代码双写，也分别介绍了两种方案的实现原理及优缺点，最后基于业务考虑选择了双写。两种方案都需要自己去写代码实现整套方案，那么如果不想自己实现怎么办呢？

        其实ShardingSphere官方提供了平滑数据迁移的方案，这节就简单介绍一下官方方案的操作步骤及原理，以及官方的方案有哪些优缺点，适不适合自己的业务场景。

ShardingSphere平滑数据迁移方案介绍

目前的数据迁移解决方案为：使用一个全新的数据库集群作为迁移目标库，迁移到的目标库不能跟原来的数据库相同。

一次数据迁移包括以下几个主要阶段：

1. 准备阶段；
2. 存量数据迁移阶段；
3. 增量数据同步阶段（其实也是使用的MySQL的binlog日志进行增量同步的）；
4. 数据一致性校验阶段；
5. 流量切换阶段。

官方文档地址

注意：官方的迁移方案使用的代理模式，也就是ShardingSphere-Proxy

运行部署地址：运行部署 :: ShardingSphere

使用手册地址：使用手册 :: ShardingSphere

执行阶段说明

准备阶段

在准备阶段，数据迁移模块会进行数据源连通性及权限的校验，同时进行存量数据的统计、日志位点的记录，最后根据数据量和用户设置的并行度，对任务进行分片。

存量数据迁移阶段

执行在准备阶段拆分好的存量数据迁移任务，存量迁移阶段采用 JDBC 查询的方式，直接从源端读取数据，基于配置的分片等规则写入到目标端。

增量数据同步阶段

由于存量数据迁移耗费的时间受到数据量和并行度等因素影响，此时需要对这段时间内业务新增的数据进行同步。 不同的数据库使用的技术细节不同，但总体上均为基于复制协议或 WAL 日志实现的变更数据捕获功能。

• MySQL：订阅并解析 binlog；

这些捕获的增量数据，同样会由数据迁移模块写入到新数据节点中。

数据一致性校验阶段

        数据迁移完成后，需要对迁移后的新老数据做数据一致性的校验，支持 CRC32 校验算法和 DATA_MATCH 校验算法

• CRC32_MATCH：循环冗余校验，通过校验码来判断是否存在数据不一致，效率快，但是不支持断点续传，且只支持MySQL

• DATA_MATCH：逐行挨个比对数据，效率稍慢但是支持断点续传和异构数据库

目标端开启数据加密的情况需要使用 DATA_MATCH，异构迁移也需要使用 DATA_MATCH。

流量切换阶段

当增量数据基本同步完成时（由于业务系统未停止，增量数据是不断的），则进入流量切换阶段。

在此阶段，可能存在一定时间的业务只读窗口期，通过设置数据库只读、控制源头写流量等方式，让源端数据节点中的数据短暂静态，确保增量同步完全完成。

这个只读窗口期时长取决于用户是否需要对数据进行一致性校验以及数据量。一致性校验是独立的任务，支持单独启停，支持断点续传。

确认完成后，数据迁移完成。 然后用户可以把读流量或者写流量切换到ShardingSphere。

官方方案的优缺点

优点

存量迁移、增量同步、数据校验都有完整的方案

不用自己设计方案，写代码了，节省了工作量

缺点

• 不支持在当前存储节点之上做迁移，需要准备一个全新的数据库集群作为迁移目标库，比如在原来的单库做分表就不支持；
• 切写流量时要设置原库只读，以避免新的数据进来，对业务有影响
• 不支持目标端表结构和源端不一致；
• 不支持迁移过程中源端表结构变更
• 不支持目标端 proxy 使用 HINT 分片策略；

        关于平滑数据迁移的方案，总共介绍了三个：canal同步binlog、代码双写、ShardingSphere官方提供的方案，具体用哪一种，需要根据以下情况综合考虑分析：

• 具体的分库分表情况
• 业务能不能接受短暂停写
• 开发团队对分库分表方案的了解程度
• 。。。。。。