Manual

Manual

Environment

JAVA,JDK 1.8+.

The migration scene we support:

SourceTarget
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)

Attention:

If the backend database is in following table, please download JDBC driver jar and put it into ${shardingsphere-proxy}/lib directory.

RDBMSJDBC driverReference
MySQLmysql-connector-java-5.1.47.jarConnector/J Versions
openGaussopengauss-jdbc-2.0.1-compatibility.jar

Supported features:

FeatureMySQLPostgreSQLopenGauss
Inventory migrationSupportedSupportedSupported
Incremental migrationSupportedSupportedSupported
Create table automaticallySupportedUnsupportedSupported
DATA_MATCH data consistency checkSupportedSupportedSupported
CRC32_MATCH data consistency checkSupportedUnsupportedUnsupported

Attention:

For RDBMS which Create table automatically feature is not supported, we need to create sharding tables manually.

Privileges

MySQL

  1. Enable binlog

Configuration Example of MySQL 5.7 my.cnf:

  1. [mysqld]
  2. server-id=1
  3. log-bin=mysql-bin
  4. binlog-format=row
  5. binlog-row-image=full
  6. max_connections=600

Execute the following SQL to confirm whether binlog is turned on or not:

  1. show variables like '%log_bin%';
  2. show variables like '%binlog%';

As shown below, it means binlog has been turned on:

  1. +-----------------------------------------+---------------------------------------+
  2. | Variable_name | Value |
  3. +-----------------------------------------+---------------------------------------+
  4. | log_bin | ON |
  5. | binlog_format | ROW |
  6. | binlog_row_image | FULL |
  7. +-----------------------------------------+---------------------------------------+
  1. Privileges of account that scaling use should include Replication privileges.

Execute the following SQL to confirm whether the user has migration permission or not:

  1. SHOW GRANTS 'user';

Result Example:

  1. +------------------------------------------------------------------------------+
  2. |Grants for ${username}@${host} |
  3. +------------------------------------------------------------------------------+
  4. |GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO ${username}@${host} |
  5. |....... |
  6. +------------------------------------------------------------------------------+

PostgreSQL

  1. Enable test_decoding feature.

  2. Adjust WAL configuration

Configuration Example of postgresql.conf:

  1. wal_level = logical
  2. max_replication_slots = 10

Please refer to Write Ahead Log and Replication for more details.

DistSQL API for auto mode

Preview current sharding rule

Example:

  1. preview select count(1) from t_order;

Response:

  1. mysql> preview select count(1) from t_order;
  2. +------------------+--------------------------------+
  3. | data_source_name | sql |
  4. +------------------+--------------------------------+
  5. | ds_0 | select count(1) from t_order_0 |
  6. | ds_0 | select count(1) from t_order_1 |
  7. | ds_1 | select count(1) from t_order_0 |
  8. | ds_1 | select count(1) from t_order_1 |
  9. +------------------+--------------------------------+
  10. 4 rows in set (0.00 sec)

Start scaling job

  1. Add new data source resources

Please refer to RDL#Data Source for more details.

Create database on underlying RDBMS first, it will be used in following DistSQL.

Example:

  1. ADD RESOURCE ds_2 (
  2. URL="jdbc:mysql://127.0.0.1:3306/scaling_ds_2?serverTimezone=UTC&useSSL=false",
  3. USER=root,
  4. PASSWORD=root,
  5. PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
  6. ), ds_3 (
  7. URL="jdbc:mysql://127.0.0.1:3306/scaling_ds_3?serverTimezone=UTC&useSSL=false",
  8. USER=root,
  9. PASSWORD=root,
  10. PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
  11. ), ds_4 (
  12. URL="jdbc:mysql://127.0.0.1:3306/scaling_ds_4?serverTimezone=UTC&useSSL=false",
  13. USER=root,
  14. PASSWORD=root,
  15. PROPERTIES("maximumPoolSize"=10,"idleTimeout"="30000")
  16. );
  1. Alter all sharding table rule

Currently, scaling job could only be emitted by executing ALTER SHARDING TABLE RULE DistSQL.

Please refer to RDL#Sharding for more details.

SHARDING TABLE RULE support two types: TableRule and AutoTableRule. Following is a comparison of the two sharding rule types:

TypeAutoTableRuleTableRule
DefinitionAuto Sharding AlgorithmUser-Defined Sharding Algorithm

Meaning of fields in DistSQL is the same as YAML configuration, please refer to YAML Configuration#Sharding for more details.

Example of alter AutoTableRule:

  1. ALTER SHARDING TABLE RULE t_order (
  2. RESOURCES(ds_2, ds_3, ds_4),
  3. SHARDING_COLUMN=order_id,
  4. TYPE(NAME=hash_mod,PROPERTIES("sharding-count"=6)),
  5. GENERATED_KEY(COLUMN=order_id,TYPE(NAME=snowflake,PROPERTIES("worker-id"=123)))
  6. );

RESOURCES is altered from (ds_0, ds_1) to (ds_2, ds_3, ds_4), and sharding-count is altered from 4 to 6, it will emit scaling job.

Uncompleted example of alter TableRule:

  1. ALTER SHARDING ALGORITHM database_inline (
  2. TYPE(NAME=INLINE,PROPERTIES("algorithm-expression"="ds_${user_id % 3 + 2}"))
  3. );
  4. ALTER SHARDING TABLE RULE t_order (
  5. DATANODES("ds_${2..4}.t_order_${0..1}"),
  6. DATABASE_STRATEGY(TYPE=standard,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM=database_inline),
  7. TABLE_STRATEGY(TYPE=standard,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_inline),
  8. GENERATED_KEY(COLUMN=order_id,TYPE(NAME=snowflake,PROPERTIES("worker-id"=123)))
  9. ), t_order_item (
  10. DATANODES("ds_${2..4}.t_order_item_${0..1}"),
  11. DATABASE_STRATEGY(TYPE=standard,SHARDING_COLUMN=user_id,SHARDING_ALGORITHM=database_inline),
  12. TABLE_STRATEGY(TYPE=standard,SHARDING_COLUMN=order_id,SHARDING_ALGORITHM=t_order_item_inline),
  13. GENERATED_KEY(COLUMN=order_item_id,TYPE(NAME=snowflake,PROPERTIES("worker-id"=123)))
  14. );

algorithm-expression of database_inline is alerted from ds_${user_id % 2} to ds_${user_id % 3 + 2}, and DATANODES of t_order is alerted from ds_${0..1}.t_order_${0..1} to ds_${2..4}.t_order_${0..1}, it will emit scaling job.

Currently, ALTER SHARDING ALGORITHM will take effect immediately, but table rule will not, it might cause inserting data into source side failure, so alter sharding table rule to AutoTableRule is recommended for now.

List scaling jobs

Please refer to RAL#Scaling for more details.

Example:

  1. show scaling list;

Response:

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

Get scaling progress

Example:

  1. show scaling status {jobId};

Response:

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

Current scaling job is finished, new sharding rule should take effect, and not if scaling job is failed.

status values:

ValueDescription
PREPARINGpreparing
RUNNINGrunning
EXECUTE_INVENTORY_TASKinventory task running
EXECUTE_INCREMENTAL_TASKincremental task running
ALMOST_FINISHEDalmost finished
FINISHEDfinished (The whole process is completed, and the new rules have been taken effect)
PREPARING_FAILUREpreparation failed
EXECUTE_INVENTORY_TASK_FAILUREinventory task failed
EXECUTE_INCREMENTAL_TASK_FAILUREincremental task failed

If status fails, you can check the log of proxy to view the error stack and analyze the problem.

Preview new sharding rule

Example:

  1. preview select count(1) from t_order;

Response:

  1. mysql> preview select count(1) from t_order;
  2. +------------------+--------------------------------+
  3. | data_source_name | sql |
  4. +------------------+--------------------------------+
  5. | ds_2 | select count(1) from t_order_0 |
  6. | ds_2 | select count(1) from t_order_1 |
  7. | ds_3 | select count(1) from t_order_0 |
  8. | ds_3 | select count(1) from t_order_1 |
  9. | ds_4 | select count(1) from t_order_0 |
  10. | ds_4 | select count(1) from t_order_1 |
  11. +------------------+--------------------------------+
  12. 6 rows in set (0.01 sec)

Other DistSQL

Please refer to RAL#Scaling for more details.

DistSQL API for manual mode

Data consistency check and switch configuration could be emitted manually. Please refer to RAL#Scaling for more details.

Attention: It’s still under development.