ShardingSphere > 用户手册 > ShardingSphere-Scaling > 使用手册

使用手册

环境要求

纯 JAVA 开发，JDK 建议 1.8 以上版本。

支持迁移场景如下：

源端	目标端
MySQL(5.1.15 ~ 5.7.x)	MySQL(5.1.15 ~ 5.7.x)
PostgreSQL(9.4 ~ )	PostgreSQL(9.4 ~ )
openGauss(2.1.0)	openGauss(2.1.0)

注意：

如果后端连接以下数据库，请下载相应JDBC驱动jar包，并将其放入 ${shardingsphere-proxy}/lib 目录。

数据库	JDBC驱动	参考
MySQL	mysql-connector-java-5.1.47.jar	Connector/J Versions
openGauss	opengauss-jdbc-2.0.1-compatibility.jar

功能支持情况：

功能	MySQL	PostgreSQL	openGauss
全量迁移	支持	支持	支持
增量迁移	支持	支持	支持
自动建表	支持	不支持	支持
DATA_MATCH一致性校验	支持	支持	支持
CRC32_MATCH一致性校验	支持	不支持	不支持

注意：

还没开启自动建表的数据库需要手动创建分表。

权限要求

MySQL

开启 binlog

MySQL 5.7 my.cnf 示例配置：

[mysqld]
server-id=1
log-bin=mysql-bin
binlog-format=row
binlog-row-image=full
max_connections=600

执行以下命令，确认是否有开启binlog：

show variables like '%log_bin%';
show variables like '%binlog%';

如以下显示，则说明binlog已开启

+-----------------------------------------+---------------------------------------+
| Variable_name                           | Value                                 |
+-----------------------------------------+---------------------------------------+
| log_bin                                 | ON                                    |
| binlog_format                           | ROW                                   |
| binlog_row_image                        | FULL                                  |
+-----------------------------------------+---------------------------------------+

赋予 MySQL 账号 Replication 相关权限。

执行以下命令，查看该用户是否有迁移权限：

SHOW GRANTS 'user';

示例结果：

+------------------------------------------------------------------------------+
|Grants for ${username}@${host}                                                |
+------------------------------------------------------------------------------+
|GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ${username}@${host}     |
|.......                                                                       |
+------------------------------------------------------------------------------+

PostgreSQL

开启 test_decoding
调整 WAL 配置

postgresql.conf 示例配置：

wal_level = logical
max_replication_slots = 10

详情请参见 Write Ahead Log 和 Replication。

DistSQL 自动模式接口

预览当前分片规则

示例：

preview select count(1) from t_order;

返回信息：

mysql> preview select count(1) from t_order;
+------------------+--------------------------------+
| data_source_name | sql                            |
+------------------+--------------------------------+
| ds_0             | select count(1) from t_order_0 |
| ds_0             | select count(1) from t_order_1 |
| ds_1             | select count(1) from t_order_0 |
| ds_1             | select count(1) from t_order_1 |
+------------------+--------------------------------+
4 rows in set (0.00 sec)

创建迁移任务

添加新的数据源

详情请参见RDL#数据源资源。

先在底层数据库系统创建需要的分库，下面的 DistSQL 需要用到。

示例：

ADD RESOURCE ds_2 (
    URL="jdbc:mysql://127.0.0.1:3306/scaling_ds_2?serverTimezone=UTC&useSSL=false",
    USER=root,
    PASSWORD=root,
    PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
), ds_3 (
    URL="jdbc:mysql://127.0.0.1:3306/scaling_ds_3?serverTimezone=UTC&useSSL=false",
    USER=root,
    PASSWORD=root,
    PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
), ds_4 (
    URL="jdbc:mysql://127.0.0.1:3306/scaling_ds_4?serverTimezone=UTC&useSSL=false",
    USER=root,
    PASSWORD=root,
    PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
);

修改所有表的分片规则

目前只有通过执行 ALTER SHARDING TABLE RULE DistSQL 来触发迁移。

详情请参见RDL#数据分片。

SHARDING TABLE RULE支持 2 种类型：TableRule和AutoTableRule。以下是两种分片规则的对比：

类型	AutoTableRule（自动分片）	TableRule（自定义分片）
定义	自动化分片算法	自定义分片算法

DistSQL 字段含义和 YAML 配置保持一致，详情请参见YAML配置#数据分片。

AutoTableRule修改示例：

ALTER SHARDING TABLE RULE t_order (
RESOURCES(ds_2, ds_3, ds_4),
SHARDING_COLUMN=order_id,
TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=6)),
KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME=snowflake))
);

RESOURCES 从 (ds_0, ds_1) 改为了 (ds_2, ds_3, ds_4)，sharding-count 从 4 改为了 6，会触发迁移。

TableRule修改示例：

ALTER SHARDING ALGORITHM database_inline (
TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="ds_${user_id % 3 + 2}"))
);

ALTER SHARDING TABLE RULE t_order (
DATANODES("ds_${2..4}.t_order_${0..1}"),
DATABASE_STRATEGY(TYPE=standard,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM=database_inline),
TABLE_STRATEGY(TYPE=standard,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_inline),
KEY_GENERATE_STRATEGY(COLUMN=order_id,TYPE(NAME=snowflake))
), t_order_item (
DATANODES("ds_${2..4}.t_order_item_${0..1}"),
DATABASE_STRATEGY(TYPE=standard,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM=database_inline),
TABLE_STRATEGY(TYPE=standard,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_item_inline),
KEY_GENERATE_STRATEGY(COLUMN=order_item_id,TYPE(NAME=snowflake))
);

database_inline 的 algorithm-expression 从 ds_${user_id % 2} 改为 ds_${user_id % 3 + 2}，t_order 的 DATANODES 从 ds_${0..1}.t_order_${0..1} 改为 ds_${2..4}.t_order_${0..1}，会触发迁移。

目前 ALTER SHARDING ALGORITHM 会即时生效、但是规则还没生效，可能会导致源端 insert 异常，所以建议优先修改为 AutoTableRule。

查询所有迁移任务

详情请参见RAL#弹性伸缩。

示例：

show scaling list;

返回信息：

mysql> show scaling list;
+--------------------+-----------------------+----------------------+--------+---------------------+---------------------+
| id                 | tables                | sharding_total_count | active | create_time         | stop_time           |
+--------------------+-----------------------+----------------------+--------+---------------------+---------------------+
| 659853312085983232 | t_order_item, t_order | 2                    | false  | 2021-10-26 20:21:31 | 2021-10-26 20:24:01 |
| 660152090995195904 | t_order_item, t_order | 2                    | false  | 2021-10-27 16:08:43 | 2021-10-27 16:11:00 |
+--------------------+-----------------------+----------------------+--------+---------------------+---------------------+
2 rows in set (0.04 sec)

查询迁移任务进度

示例：

show scaling status {jobId};

返回信息：

mysql> show scaling status 660152090995195904;
+------+-------------+----------+-------------------------------+--------------------------+
| item | data_source | status   | inventory_finished_percentage | incremental_idle_minutes |
+------+-------------+----------+-------------------------------+--------------------------+
| 0    | ds_1        | FINISHED | 100                           | 2834                     |
| 1    | ds_0        | FINISHED | 100                           | 2834                     |
+------+-------------+----------+-------------------------------+--------------------------+
2 rows in set (0.00 sec)

当前迁移任务已完成，新的分片规则已生效。如果迁移失败，新的分片规则不会生效。

status的取值：

取值	描述
PREPARING	准备中
RUNNING	运行中
EXECUTE_INVENTORY_TASK	全量迁移中
EXECUTE_INCREMENTAL_TASK	增量迁移中
FINISHED	已完成（整个流程完成了，新规则已生效）
PREPARING_FAILURE	准备阶段失败
EXECUTE_INVENTORY_TASK_FAILURE	全量迁移阶段失败
EXECUTE_INCREMENTAL_TASK_FAILURE	增量迁移阶段失败

如果status出现失败的情况，可以查看proxy的日志查看错误堆栈分析问题。

预览新的分片规则是否生效

示例：

preview select count(1) from t_order;

返回信息：

mysql> preview select count(1) from t_order;
+------------------+--------------------------------+
| data_source_name | sql                            |
+------------------+--------------------------------+
| ds_2             | select count(1) from t_order_0 |
| ds_2             | select count(1) from t_order_1 |
| ds_3             | select count(1) from t_order_0 |
| ds_3             | select count(1) from t_order_1 |
| ds_4             | select count(1) from t_order_0 |
| ds_4             | select count(1) from t_order_1 |
+------------------+--------------------------------+
6 rows in set (0.01 sec)

其他DistSQL

详情请参见RAL#弹性伸缩。

DistSQL 手动模式接口

数据校验、切换配置等操作可以手动执行。详情请参见：RAL#弹性伸缩。

注意：目前还在开发中，功能还不完善。