Shardingsphere-Proxy 5.5.0数据迁移
Shardingsphere系列目录:
【Springboot 集成 Shardingsphere-JDBC】
【Shardingsphere-Proxy 5.5.0部署】
【Shardingsphere-Proxy 5.5.0数据迁移】
背景
继上一篇【Shardingsphere-Proxy 5.5.0部署】 部署完了Shardingsphere-Proxy,方便在线下查询数据;但是分库分表实现了,但是老数据怎么办,难道还让那4000w+的数据待在那里不动?这样不就造成数据倾斜了吗?所以咱们需要将原先的老数据按照分库分表规则迁移到分片表。
配置集群部署
原先咱们之前部署的shardingsphere-proxy是单机模式(Standalone),但是数据迁移的前提就是需要部署集群模式(Cluster)的shardingsphere-proxy,这个也不难,做以下三步即可:
- 搭建Zookeeper
- 修改shardingsphere-proxy配置为集群模式
- 重启shardingsphere-proxy
搭建Zookeeper
按照【Zookeeper部署】 步骤安装。
修改shardingsphere-proxy配置
在原global.yaml配置基础上,新增配置如下:
mode:
# 集群模式
type: Cluster
repository:
# 持久化仓库类型
type: ZooKeeper
# 持久化仓库所需属性
props:
# 注册中心命名空间
namespace: governance_ds
# 注册中心连接地址(zookeeper的客户端连接端口)
server-lists: localhost:2181
以上配置中的namespace可借鉴【Zookeeper部署】中对namespace的配置,其中namespace列表中的元素可选一个填写到此处。
重启shardingsphere-proxy
进入【bin】目录,执行关闭指令:
./stop.sh
进入【bin】目录,执行启动指令:
./start.sh
执行数据迁移
连接代理数据库实例(Navicate)
借鉴【Shardingsphere-Proxy 5.5.0部署】中的Navicate连接代理数据库方法。
应用代理数据库
use sharding_test_db;
注册目标分片数据库存储单元
注:建议这里配置的数据库连接ip使用【公网地址】,之前碰到过迁移数据失败问题,查看其他配置实在没问题,将这里修改为用公网地址连接数据库后迁移成功
REGISTER STORAGE UNIT target_test_0 (
URL="jdbc:mysql://localhost:3306/test_db_0?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true",
USER="root",
PASSWORD="123456"
);
REGISTER STORAGE UNIT target_test_1 (
URL="jdbc:mysql://localhost:3306/test_db_1?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true",
USER="root",
PASSWORD="123456"
);
注销目标分片数据库存储单元
如果存储单元有修改,可以注销后重新注册。
UNREGISTER STORAGE UNIT IF EXISTS 目标存储单元别名;
例:UNREGISTER STORAGE UNIT IF EXISTS target_tss_1;
注意:注销之前要将已经创建的分库分表规则先删除
创建分库分表规则
规则名是proxy代理数据库汇聚的表名
CREATE SHARDING TABLE RULE test_table(
DATANODES("target_tss_${0..1}.test_table_${1..31}"),
DATABASE_STRATEGY(TYPE="standard",SHARDING_COLUMN=id,SHARDING_ALGORITHM(TYPE(NAME="inline",PROPERTIES("algorithm-expression"="target_tss_${id % 2}")))),
TABLE_STRATEGY(TYPE="standard",SHARDING_COLUMN=stat_date,SHARDING_ALGORITHM(TYPE(NAME="inline",PROPERTIES("algorithm-expression"="test_table_$->{Integer.parseInt(stat_date.toString().substring(8))}")))),
KEY_GENERATE_STRATEGY(COLUMN=another_id,TYPE(NAME="snowflake"))
);
sql讲解:
DATABASE_STRATEGY:数据库分片策略(按照id字段取模分片)
TABLE_STRATEGY:表分片策略(按照stat_date字段yyyy-MM-dd时间格式的最后两位并转数字作为分片表后缀)
KEY_GENERATE_STRATEGY:主键生成策略(雪花算法)
这个例子是标准分片的一个例子,可以借鉴【shardingsphere官网】看其他的分片类型例子。
删除规则
如果规则有修改,可以删除后重新添加。有修改语法,但是我感觉先删后增更方便。
DROP SHARDING TABLE RULE IF EXISTS 规则别名;
例:DROP SHARDING TABLE RULE IF EXISTS test_table;
注册源数据库存储单元
注:可能会碰到连接数据库失败情况,建议这里配置的数据库连接ip使用【公网地址】
REGISTER MIGRATION SOURCE STORAGE UNIT source_tss (
URL="jdbc:mysql://localhost:3306/test_db?serverTimezone=UTC&useSSL=false",
USER="root",
PASSWORD="123456",
PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);
注销源数据库存储单元
如果存储单元有修改,可以注销后重新注册。
UNREGISTER MIGRATION SOURCE STORAGE UNIT 存储单元别名;
例:UNREGISTER MIGRATION SOURCE STORAGE UNIT source_tss;
查询数据迁移规则
SHOW MIGRATION RULE;
修改数据迁移规则
用于配置在原库查询数据及在目标库插入数据的线程数、QPS、TPS
因 migration rule 具有默认值,无需创建,仅提供 ALTER 语句。
ALTER MIGRATION RULE (
READ( -- 数据读取配置。如果不配置则部分参数默认生效。
WORKER_THREAD=40, -- 从源端摄取全量数据的线程池大小。如果不配置则使用默认值。
BATCH_SIZE=1000, -- 一次查询操作返回的最大记录数。如果不配置则使用默认值。
SHARDING_SIZE=10000000, -- 全量数据分片大小。如果不配置则使用默认值。
RATE_LIMITER ( -- 限流算法。如果不配置则不限流。
TYPE( -- 算法类型。可选项:QPS
NAME='QPS',
PROPERTIES( -- 算法属性
'qps'='500'
)))
),
WRITE( -- 数据写入配置。如果不配置则部分参数默认生效。
WORKER_THREAD=40, -- 数据写入到目标端的线程池大小。如果不配置则使用默认值。
BATCH_SIZE=1000, -- 一次批量写入操作的最大记录数。如果不配置则使用默认值。
RATE_LIMITER ( -- 限流算法。如果不配置则不限流。
TYPE( -- 算法类型。可选项:TPS
NAME='TPS',
PROPERTIES( -- 算法属性
'tps'='2000'
)))
),
STREAM_CHANNEL ( -- 数据通道,连接生产者和消费者,用于 read 和 write 环节。如果不配置则默认使用 MEMORY 类型。
TYPE( -- 算法类型。可选项:MEMORY
NAME='MEMORY',
PROPERTIES( -- 算法属性
'block-queue-size'='10000' -- 属性:阻塞队列大小
)))
);
执行迁移任务
MIGRATE TABLE 源数据库存储单元别名.源表名 INTO 分库分表汇聚表名;
例:MIGRATE TABLE source_tss.test_table INTO test_table;
注意:【执行迁移任务】操作后,【提交任务】操作前,这个任务会持续执行,对于【存量数据】以及【增量数据】都会迁移到目标分片表。
查询数据迁移任务列表
可查询任务id
SHOW MIGRATION LIST;
查询指定任务id的状态
其中包含迁移数据行数(processed_records_count
)以及迁移进度百分比(inventory_finished_percentage
)
SHOW MIGRATION STATUS '任务id';
执行检查数据一致性任务
注意:该数据迁移任务已经完成,才可以执行该命令
CHECK MIGRATION '任务id' BY TYPE (NAME='CRC32_MATCH');
数据一致性校验算法类型来自:
SHOW MIGRATION CHECK ALGORITHMS;
注意:
- 目标端开启数据加密的情况需要使用
DATA_MATCH
。- 异构迁移需要使用
DATA_MATCH
。
查询数据一致性检查结果
SHOW MIGRATION CHECK STATUS '任务id';
提交任务
COMMIT MIGRATION '任务id';
注意:
- 同一个表执行的迁移任务id相同,如果想多次执行同一个表的迁移任务,需要【提交任务】提交完之后可循环执行
- 【执行迁移任务】目标表需要为空,报错信息可在【查询指定任务id的状态】列表的【error_message】字段查看
- 集群模式修改配置文件中的表分片逻辑后可能会无效,因为有缓存的缘故,我的做法是
把zookeeper和shardingsphere-proxy重启
就可以了,如果还是无效,那就在zookeeper创建一个新的namespace并应用在shardingsphere代理中
。
数据迁移执行 DistSQL 脚本实战
-- 1. 应用代理数据库
use sharding_test_db;
-- 2. 注册目标数据库存储单元
REGISTER STORAGE UNIT target_test_0 (
URL="jdbc:mysql://localhost:3306/test_db_0?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true",
USER="root",
PASSWORD="123456"
);
REGISTER STORAGE UNIT target_test_1 (
URL="jdbc:mysql://localhost:3306/test_db_1?serverTimezone=UTC&useSSL=false&allowPublicKeyRetrieval=true",
USER="root",
PASSWORD="123456"
);
-- 3. 创建规则(规则名是proxy代理数据库汇聚的表名)(表规则取yyyy-MM-dd后两位并转数字最为分片表后缀)
CREATE SHARDING TABLE RULE test_table(
DATANODES("target_tss_${0..1}.test_table_${1..31}"),
DATABASE_STRATEGY(TYPE="standard",SHARDING_COLUMN=id,SHARDING_ALGORITHM(TYPE(NAME="inline",PROPERTIES("algorithm-expression"="target_tss_${id % 2}")))),
TABLE_STRATEGY(TYPE="standard",SHARDING_COLUMN=stat_date,SHARDING_ALGORITHM(TYPE(NAME="inline",PROPERTIES("algorithm-expression"="test_table_$->{Integer.parseInt(stat_date.toString().substring(8))}")))),
KEY_GENERATE_STRATEGY(COLUMN=another_id,TYPE(NAME="snowflake"))
);
-- 4. 注册源数据库存储单元
REGISTER MIGRATION SOURCE STORAGE UNIT source_tss (
URL="jdbc:mysql://localhost:3306/test_db?serverTimezone=UTC&useSSL=false",
USER="root",
PASSWORD="123456",
PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);
-- 5. 执行迁移任务
MIGRATE TABLE source_tss.test_table INTO test_table;
-- 6. 展示数据迁移任务列表
SHOW MIGRATION LIST;
-- 7. 查询指定任务id的状态
SHOW MIGRATION STATUS 'j0102p00004fbcfe6b4dc23af37e3cdb06a4c634ed';
-- 8. 提交任务
COMMIT MIGRATION 'j0102p00004fbcfe6b4dc23af37e3cdb06a4c634ed';