实现原理
思考到 ShardingSphere 的弹性伸缩模块的几个挑战，目前的弹性伸缩解决方案为：长期地应用两个数据库集群，伸缩实现后切换的形式实现。
这种实现形式有以下长处：
- 伸缩过程中，原始数据没有任何影响。
- 伸缩失败无风险。
- 不受分片策略限度。
同时也存在肯定的毛病：
- 在肯定工夫内存在冗余服务器
- 所有数据都须要挪动
弹性伸缩模块会通过解析旧分片规定，提取配置中的数据源、数据节点等信息，之后创立伸缩作业工作流，将一次弹性伸缩拆解为 4 个次要阶段
- 筹备阶段
- 存量数据迁徙阶段
- 增量数据同步阶段
- 规定切换阶段
筹备阶段
在筹备阶段，弹性伸缩模块会进行数据源连通性及权限的校验，同时进行存量数据的统计、日志位点的记录，最初依据数据量和用户设置的并行度，对工作进行分片。
存量数据迁徙阶段
执行在筹备阶段拆分好的存量数据迁徙作业，存量迁徙阶段采纳 JDBC 查问的形式，间接从数据节点中读取数据，并应用新规定写入到新集群中。
增量数据同步阶段
因为存量数据迁徙消耗的工夫受到数据量和并行度等因素影响，此时须要对这段时间内业务新增的数据进行同步。不同的数据库应用的技术细节不同，但总体上均为基于复制协定或 WAL 日志实现的变更数据捕捉性能。
- MySQL：订阅并解析 binlog
- PostgreSQL：采纳官网逻辑复制 test_decoding
这些捕捉的增量数据，同样会由弹性伸缩模块依据新规定写入到新数据节点中。当增量数据根本同步实现时（因为业务零碎未进行，增量数据是一直的），则进入规定切换阶段。
规定切换阶段
在此阶段，可能存在肯定工夫的业务只读窗口期，通过设置数据库只读或 ShardingSphere 的熔断机制，让旧数据节点中的数据短暂动态，确保增量同步已齐全实现。
这个窗口期工夫短则数秒，长则数分钟，取决于数据量和用户是否须要对数据进行强校验。确认实现后，ShardingSphere 可通过配置核心批改配置，将业务导向新规定的集群，弹性伸缩实现。