郭信泽-基于 Apache ShardingSphere 改造单机数据库为分布式数据库实战-ShardingSphere Meetup 上海站

1 .「Apache ShardingSphere 2023 Meetup」 基于 Apache ShardingSphere 改造 单机数据库为分布式数据库实战 郭信泽 

2 .目录 1 Apache ShardingSphere 介绍 0 2 2 Apache ShardingSphere 构建分布式数据库实战 0 3 3 数据二次迁移的实现及思考 

3 .01 Apache ShardingSphere 介绍 

4 .ShardingSphere 介绍 

5 .ShardingSphere Proxy 介绍 ShardingSphere-Proxy 定位为透明化的数据库代理端，通过实现数据库二进制协议，对异构语言提供支持。 目 前提供 MySQL 和 PostgreSQL 协议，透明化数据库操作，对 DBA 更加友好。 

6 .ShardingSphere 数据分片介绍 数据分片是 ShardingSphere 最核心的功能 常见的分片算法 1. 基于取模的分片算法 2. 基于时间范围的分片算法 

7 .ShardingSphere 读写分离介绍 > 将数据库拆分为主库和从库 • 主库负责处理事务性的增删改操作 • 从库负责处理查询操作 能够有效的避免由数据更新导致的行锁，使得整 个系统的查询性能得到极大的改善。 > 读写分离则是根据 SQL 语义的分析，将写操 作和读操作分别路由至主库与从库。 

8 .ShardingSphere 数据加密介绍 

9 .02 Apache ShardingSphere 构建分布式数据库 实战 

10 .环境准备 1. ShardingSphere 版本 5.3.0 or master branch & cluster mode 2. MySQL数据库 源端1台，目标端2台（一主一从），共计3台数据库 3. 注册中心 ZooKeeper 3.8.0 

11 .部署架构 

12 .数据迁移原理 迁移主要分为 4 个阶段 准备阶段 存量迁移阶段 增量迁移阶段 流量切换阶段 由于存量数据迁移耗费的时间 在准备阶段，数据迁移模 受到数据量和并行度等因素影 响，需要对这段时间内业务新 块会进行数据源连通性及 存量迁移阶段采用 JDBC 迁移完成后，用户可以把 增的数据进行同步。 MySQL 权限的校验，同时进行存 查询的方式，直接从源端 读流量或者写流量切换到 是通过订阅并解析 binlog实现 量数据的统计、日志位点 读取数据，基于配置的分 Apache 的，当增量数据基本同步完成 的记录，进行任务的初始 片等规则写入到目标端。 ShardingSphere。 时（由于业务系统未停止，增 化。 量数据是不断的），则进入流 量切换阶段。 

13 .源端数据初始化及权限配置 

14 .启动 ShardingSphere Proxy 1. 使用集群模式启动 ShardingSphere Proxy，核心配 3. 在 ShardingSphere Proxy 上创建数据库 置信息如下 mode: type: Cluster repository: type: ZooKeeper props: namespace: governance_ds server-lists: localhost:2181 authority: users: - user: root@% password: root 2. 使用 client 连接上 proxy mysql -u root -P3307 -h 127.0.0.1 -p 

15 .初始化存储单元 使用 DistSQL 添加存储单元 REGISTER STORAGE UNIT target_ds_0 ( URL="jdbc:mysql://${target_databse_url:port}/target_ds_0?serverTimezone=UTC&useSSL=false", USER="target_user", PASSWORD="123456" ); REGISTER STORAGE UNIT target_ds_1 ( URL="jdbc:mysql://${target_databse_url:port}/target_ds_1?serverTimezone=UTC&useSSL=false", USER="target_user", PASSWORD="123456" ); REGISTER STORAGE UNIT read_ds_0 ( URL="jdbc:mysql://${read_databse_url:port}/target_ds_0?serverTimezone=UTC&useSSL=false", USER="target_user", PASSWORD="123456" ); REGISTER STORAGE UNIT read_ds_1 ( URL="jdbc:mysql://${read_databse_url:port}/target_ds_1?serverTimezone=UTC&useSSL=false", USER="target_user", PASSWORD="123456" ); 需要注意，由于迁移会涉及到自动建表、建索引，所以使用的是普通账户，需要提前赋予相应的权限 GRANT CREATE, ALTER, DROP, SELECT, INSERT, UPDATE, DELETE, INDEX ON target_ds_0.* TO target_user; GRANT CREATE, ALTER, DROP, SELECT, INSERT, UPDATE, DELETE, INDEX ON target_ds_1.* TO target_user; 

16 .初始化规则定义 1. 初始化读写分离规则，后续迁移使用的是这里的逻辑源 CREATE READWRITE_SPLITTING RULE rw_ds_0 ( WRITE_STORAGE_UNIT=target_ds_0, READ_STORAGE_UNITS(read_ds_0), TYPE(NAME="random") ); CREATE READWRITE_SPLITTING RULE rw_ds_1 ( WRITE_STORAGE_UNIT=target_ds_1, READ_STORAGE_UNITS(read_ds_1), TYPE(NAME="random") ); 2. 初始化分片规则 CREATE SHARDING TABLE RULE t_user( STORAGE_UNITS(rw_ds_0, rw_ds_1), SHARDING_COLUMN=id, TYPE(NAME="hash_mod",PROPERTIES("sharding-count"="16")), KEY_GENERATE_STRATEGY(COLUMN=id,TYPE(NAME="snowflake")) ); 3. 初始化加密规则 CREATE ENCRYPT RULE t_user ( COLUMNS((NAME=password, PLAIN=password, CIPHER=password_cipher, ENCRYPT_ALGORITHM(TYPE(NAME='AES',PROPERTIES('aes- key-value'='123456abc'))))),QUERY_WITH_CIPHER_COLUMN=false ); 

17 .进行数据迁移 1. 添加迁移数据源 REGISTER MIGRATION SOURCE STORAGE UNIT source_ds ( URL="jdbc:mysql://${source_database_url:port}/source_ds?serverTimezone=UTC&useSSL=false", USER="source_user", PASSWORD="123456" ); 2. 执行迁移命令 MIGRATE TABLE source_ds.t_user INTO sharding_db.t_user; 3. 查询迁移进度 通过 SHOW MIGRATION LIST; 查询迁移作业列表 通过 SHOW MIGRATION STATUS 'jobId'; 查询作业详情 

18 .进行数据迁移 迁移的过程中 1. 全量和增量衔接，确保数据的完整性 2. 会进行部分 SQL 改写，确保插入操作是幂等的 3. 全量阶段是会对数据的插入做一些优化 

19 .验证迁移前后的数据结构及加密 迁移前 迁移后 

20 .验证迁移前后的数据一致性 前置条件： • 数据迁移进入到增量迁移的阶段 • 需要一定时间的业务只读窗口期 MySQL 支持 CRC32 校验算法和 DATA_MATCH 校验算法 • CRC32_MATCH：循环冗余校验，通过校验码来判断是否存在数据不一致，效率快，但是不支持断点续传，且只支 持MySQL • DATA_MATCH：逐行挨个比对数据，效率稍慢但是支持断点续传和异构数据库 校验通过之后，用户可以自行选择何时进行流量的切换 

21 .提交作业并刷新table元数据 提交操作主要是做一些收尾的操作，例如清理 PostgreSQL 的 slot，在 MySQL 下不是必须的 最后刷新下table元数据 

22 .验证读写分离 使用 preview 语句预览执行 select 和 update 的路由结果 

23 .03 数据二次迁移的实现及思考 

24 .二次数据迁移的业务场景 业务的极速增长 

25 .二次数据迁移的实现 如何通过 ShardingSphere 提供的迁移功能实现数据的二次迁移？ 当然可以，但是步骤会比较繁琐 

26 .二次数据迁移的思考 1. 完整的数据被拆分 在二次迁移的时候，源端的数据整体上被分割成了和物理表数量一样的小段，用户需要对每个物理表进行迁移操作，不能直观的感知到整体的迁移进度。 与此同时二次迁移前后的数据分布发生了变化，无法使用一致性校验。 2. 资源利用率较低 需要准备全新的数据库实例和 ShardingSphere Proxy 集群，同时启动多个迁移任务也会消耗系统资源。 更好的解决方案 

27 .联系我们 SphereEx Apache ShardingSphere 微信公众号 微信公众号 SphereEx 官网：https://sphere-ex.cn Open SphereEx Community：https://community.sphere-ex.com Apache ShardingSphere Website：https://shardingsphere.apache.org Apache ShardingSphere GitHub： https://github.com/apache/shardingsphere Apache ShardingSphere Slack Channel：https://apacheshardingsphere.slack.com 邮箱：it@sphere-ex.com / biz@sphere-ex.com 

28 .谢谢