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，这个也不难，做以下三步即可：

1. 搭建Zookeeper
2. 修改shardingsphere-proxy配置为集群模式
3. 重启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;

注册目标分片数据库存储单元

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;

注册源数据库存储单元

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;

执行迁移任务

MIGRATE TABLE 源数据库存储单元别名.源表名 INTO 分库分表汇聚表名;
例：MIGRATE TABLE source_tss.test_table INTO test_table;

注意：【执行迁移任务】操作后，【提交任务】操作前，这个任务会持续执行，对于【存量数据】以及【增量数据】都会迁移到目标分片表。

查询数据迁移任务列表

可查询任务id

SHOW MIGRATION LIST;

查询指定任务id的状态

SHOW MIGRATION STATUS '任务id';

提交任务

COMMIT MIGRATION '任务id';

注意：

1. 同一个表执行的迁移任务id相同，如果想多次执行同一个表的迁移任务，需要【提交任务】提交完之后可循环执行
2. 【执行迁移任务】目标表需要为空，报错信息可在【查询指定任务id的状态】列表的【error_message】字段查看
3. 集群模式修改配置文件中的表分片逻辑后可能会无效，因为有缓存的缘故，我的做法是把zookeeper和shardingsphere-proxy重启就可以了。

数据迁移执行 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';