Manual

MySQL user guide

Environment

Supported MySQL versions: 5.1.15 to 8.0.x.

Authority required

1. Enable binlog in source

MySQL 5.7 my.cnf configuration sample:

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

Run the following command and check whether binlog is enabled.

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

If the following information is displayed, binlog is enabled.

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

1. Grant Replication-related permissions for source MySQL account.

Run the following command to check whether the user has migration permission.

SHOW GRANTS FOR 'migration_user';

Result sample:

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

1. Grant DDL DML permissions for MySQL account

Source MySQL account needs SELECT permission. Example:

GRANT SELECT ON migration_ds_0.* TO `migration_user`@`%`;

Target MySQL account needs part of DDL and all DML permissions. Example:

GRANT CREATE, DROP, INDEX, SELECT, INSERT, UPDATE, DELETE ON *.* TO `migration_user`@`%`;

Please refer to MySQL GRANT

Complete procedure example

Requirements

1. Prepare the source database, table, and data in MySQL.

DROP DATABASE IF EXISTS migration_ds_0;
CREATE DATABASE migration_ds_0 DEFAULT CHARSET utf8;
USE migration_ds_0
CREATE TABLE t_order (order_id INT NOT NULL, user_id INT NOT NULL, status VARCHAR(45) NULL, PRIMARY KEY (order_id));
INSERT INTO t_order (order_id, user_id, status) VALUES (1,2,'ok'),(2,4,'ok'),(3,6,'ok'),(4,1,'ok'),(5,3,'ok'),(6,5,'ok');

1. Prepare the target database in MySQL.

DROP DATABASE IF EXISTS migration_ds_10;
CREATE DATABASE migration_ds_10 DEFAULT CHARSET utf8;
DROP DATABASE IF EXISTS migration_ds_11;
CREATE DATABASE migration_ds_11 DEFAULT CHARSET utf8;
DROP DATABASE IF EXISTS migration_ds_12;
CREATE DATABASE migration_ds_12 DEFAULT CHARSET utf8;

Procedure

1. Create a new logical database in proxy and configure storage units and rules.

CREATE DATABASE sharding_db;
USE sharding_db
REGISTER STORAGE UNIT ds_2 (
    URL="jdbc:mysql://127.0.0.1:3306/migration_ds_10?serverTimezone=UTC&useSSL=false",
    USER="root",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
), ds_3 (
    URL="jdbc:mysql://127.0.0.1:3306/migration_ds_11?serverTimezone=UTC&useSSL=false",
    USER="root",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
), ds_4 (
    URL="jdbc:mysql://127.0.0.1:3306/migration_ds_12?serverTimezone=UTC&useSSL=false",
    USER="root",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);
CREATE SHARDING TABLE RULE t_order(
STORAGE_UNITS(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"))
);

If you are migrating to a heterogeneous database, you need to execute the table-creation statements in proxy.

1. Configure the source storage units in proxy.

REGISTER MIGRATION SOURCE STORAGE UNIT ds_0 (
    URL="jdbc:mysql://127.0.0.1:3306/migration_ds_0?serverTimezone=UTC&useSSL=false",
    USER="root",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);

1. Start data migration.

MIGRATE TABLE ds_0.t_order INTO t_order;

Or you can specify a target logical database.

MIGRATE TABLE ds_0.t_order INTO sharding_db.t_order;

1. Check the data migration job list.

SHOW MIGRATION LIST;

Result example:

+---------------------------------------+---------+----------------------+--------+---------------------+-----------+
| id                                    | tables  | job_item_count       | active | create_time         | stop_time |
+---------------------------------------+---------+----------------------+--------+---------------------+-----------+
| j01016e501b498ed1bdb2c373a2e85e2529a6 | t_order | 1                    | true   | 2022-10-13 11:16:01 | NULL      |
+---------------------------------------+---------+----------------------+--------+---------------------+-----------+

1. View the data migration details.

SHOW MIGRATION STATUS 'j01016e501b498ed1bdb2c373a2e85e2529a6';

Result example:

+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+
| item | data_source | status                   | active | processed_records_count | inventory_finished_percentage | incremental_idle_seconds | error_message |
+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+
| 0    | ds_0        | EXECUTE_INCREMENTAL_TASK | true   | 6                       | 100                           | 81                       |               |
+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+

1. Verify data consistency.

CHECK MIGRATION 'j01016e501b498ed1bdb2c373a2e85e2529a6' BY TYPE (NAME='CRC32_MATCH');

Data consistency check algorithm list:

SHOW MIGRATION CHECK ALGORITHMS;

Result example:

+-------------+--------------------------------------------------------------+----------------------------+
| type        | supported_database_types                                     | description                |
+-------------+--------------------------------------------------------------+----------------------------+
| CRC32_MATCH | MySQL                                                        | Match CRC32 of records.    |
| DATA_MATCH  | SQL92,MySQL,MariaDB,PostgreSQL,openGauss,Oracle,SQLServer,H2 | Match raw data of records. |
+-------------+--------------------------------------------------------------+----------------------------+

If encrypt rule is configured in target proxy, then DATA_MATCH could be used.

If you are migrating to a heterogeneous database, then DATA_MATCH could be used.

Query data consistency check progress:

SHOW MIGRATION CHECK STATUS 'j01016e501b498ed1bdb2c373a2e85e2529a6';

Result example:

+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+
| tables  | result | finished_percentage | remaining_seconds | check_begin_time        | check_end_time          | duration_seconds | error_message |
+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+
| t_order | true   | 100                 | 0                 | 2022-10-13 11:18:15.171 | 2022-10-13 11:18:15.878 | 0                |               |
+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+

1. Commit the job.

COMMIT MIGRATION 'j01016e501b498ed1bdb2c373a2e85e2529a6';

1. Refresh table metadata.

REFRESH TABLE METADATA;

Please refer to RAL#Migration for more details.

PostgreSQL user guide

Environment

Supported PostgreSQL version: 9.4 or later.

Authority required

1. Enable test_decoding in source.

2. Modify WAL configuration in source.

postgresql.conf configuration sample:

wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
wal_sender_timeout = 0
max_connections = 600

Please refer to Write Ahead Log and Replication for details.

1. Grant replication permission for source PostgreSQL account.

pg_hba.conf instance configuration:

host replication repl_acct 0.0.0.0/0 md5

Please refer to The pg_hba.conf File for details.

1. Grant DDL DML permissions for PostgreSQL account.

If you are using a non-super admin account for migration, you need to GRANT CREATE and CONNECT privileges on the database used for migration.

GRANT CREATE, CONNECT ON DATABASE migration_ds_0 TO migration_user;

The account also needs to have access to the migrated tables and schema. Take the t_order table under test schema as an example.

\c migration_ds_0
GRANT USAGE ON SCHEMA test TO GROUP migration_user;
GRANT SELECT ON TABLE test.t_order TO migration_user;

PostgreSQL has the concept of OWNER, and if the account is the OWNER of a database, SCHEMA, or table, the relevant steps can be omitted.

Please refer to PostgreSQL GRANT

Complete procedure example

Requirements

1. Prepare the source database, table, and data in PostgreSQL.

DROP DATABASE IF EXISTS migration_ds_0;
CREATE DATABASE migration_ds_0;
\c migration_ds_0
CREATE TABLE t_order (order_id INT NOT NULL, user_id INT NOT NULL, status VARCHAR(45) NULL, PRIMARY KEY (order_id));
INSERT INTO t_order (order_id, user_id, status) VALUES (1,2,'ok'),(2,4,'ok'),(3,6,'ok'),(4,1,'ok'),(5,3,'ok'),(6,5,'ok');

1. Prepare the target database in PostgreSQL.

DROP DATABASE IF EXISTS migration_ds_10;
CREATE DATABASE migration_ds_10;
DROP DATABASE IF EXISTS migration_ds_11;
CREATE DATABASE migration_ds_11;
DROP DATABASE IF EXISTS migration_ds_12;
CREATE DATABASE migration_ds_12;

Procedure

1. Create a new logical database in proxy and configure storage units and rules.

CREATE DATABASE sharding_db;
\c sharding_db
REGISTER STORAGE UNIT ds_2 (
    URL="jdbc:postgresql://127.0.0.1:5432/migration_ds_10",
    USER="postgres",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
), ds_3 (
    URL="jdbc:postgresql://127.0.0.1:5432/migration_ds_11",
    USER="postgres",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
), ds_4 (
    URL="jdbc:postgresql://127.0.0.1:5432/migration_ds_12",
    USER="postgres",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);
CREATE SHARDING TABLE RULE t_order(
STORAGE_UNITS(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"))
);

If you are migrating to a heterogeneous database, you need to execute the table-creation statements in proxy.

1. Configure the source storage units in proxy.

REGISTER MIGRATION SOURCE STORAGE UNIT ds_0 (
    URL="jdbc:postgresql://127.0.0.1:5432/migration_ds_0",
    USER="postgres",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);

1. Enable data migration.

MIGRATE TABLE ds_0.t_order INTO t_order;

Or you can specify a target logical database.

MIGRATE TABLE ds_0.t_order INTO sharding_db.t_order;

Or you can specify a source schema name.

MIGRATE TABLE ds_0.public.t_order INTO sharding_db.t_order;

1. Check the data migration job list.

SHOW MIGRATION LIST;

Result example:

+---------------------------------------+---------+----------------------+--------+---------------------+-----------+
| id                                    | tables  | job_item_count       | active | create_time         | stop_time |
+---------------------------------------+---------+----------------------+--------+---------------------+-----------+
| j01016e501b498ed1bdb2c373a2e85e2529a6 | t_order | 1                    | true   | 2022-10-13 11:16:01 | NULL      |
+---------------------------------------+---------+----------------------+--------+---------------------+-----------+

1. View the data migration details.

SHOW MIGRATION STATUS 'j01016e501b498ed1bdb2c373a2e85e2529a6';

Result example:

+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+
| item | data_source | status                   | active | processed_records_count | inventory_finished_percentage | incremental_idle_seconds | error_message |
+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+
| 0    | ds_0        | EXECUTE_INCREMENTAL_TASK | true   | 6                       | 100                           | 81                       |               |
+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+

1. Verify data consistency.

CHECK MIGRATION 'j01016e501b498ed1bdb2c373a2e85e2529a6';
Query OK, 0 rows affected (0.09 sec)

Query data consistency check progress:

SHOW MIGRATION CHECK STATUS 'j01016e501b498ed1bdb2c373a2e85e2529a6';

Result example:

+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+
| tables  | result | finished_percentage | remaining_seconds | check_begin_time        | check_end_time          | duration_seconds | error_message |
+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+
| t_order | true   | 100                 | 0                 | 2022-10-13 11:18:15.171 | 2022-10-13 11:18:15.878 | 0                |               |
+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+

1. Commit the job.

COMMIT MIGRATION 'j01016e501b498ed1bdb2c373a2e85e2529a6';

1. Refresh table metadata.

REFRESH TABLE METADATA;

Please refer to RAL#Migration for more details.

openGauss user guide

Environment

Supported openGauss version: 2.0.1 to 3.0.0.

Authority required

1. Modify WAL configuration in source.

postgresql.conf configuration sample:

wal_level = logical
max_wal_senders = 10
max_replication_slots = 10
wal_sender_timeout = 0
max_connections = 600

Please refer to Write Ahead Log and Replication for details.

1. Grant replication permission for source openGauss account.

pg_hba.conf instance configuration:

host replication repl_acct 0.0.0.0/0 md5

Please refer to Configuring Client Access Authentication and Example: Logic Replication Code for details.

1. Grant DDL DML permissions for openGauss account.

If you are using a non-super admin account for migration, you need to GRANT CREATE and CONNECT privileges on the database used for migration.

GRANT CREATE, CONNECT ON DATABASE migration_ds_0 TO migration_user;

The account also needs to have access to the migrated tables and schema. Take the t_order table under test schema as an example.

\c migration_ds_0
GRANT USAGE ON SCHEMA test TO GROUP migration_user;
GRANT SELECT ON TABLE test.t_order TO migration_user;

openGauss has the concept of OWNER, and if the account is the OWNER of a database, SCHEMA, or table, the relevant steps can be omitted.

openGauss does not allow normal accounts to operate in public schema, so if the migrated table is in public schema, you need to authorize additional.

Please refer to openGauss GRANT

GRANT ALL PRIVILEGES TO migration_user;

Complete procedure example

Requirements

1. Prepare the source database, table, and data.

1.1. Isomorphic database.

DROP DATABASE IF EXISTS migration_ds_0;
CREATE DATABASE migration_ds_0;
\c migration_ds_0
CREATE TABLE t_order (order_id INT NOT NULL, user_id INT NOT NULL, status VARCHAR(45) NULL, PRIMARY KEY (order_id));
INSERT INTO t_order (order_id, user_id, status) VALUES (1,2,'ok'),(2,4,'ok'),(3,6,'ok'),(4,1,'ok'),(5,3,'ok'),(6,5,'ok');

1.2. Heterogeneous database.

MySQL example:

DROP DATABASE IF EXISTS migration_ds_0;
CREATE DATABASE migration_ds_0 DEFAULT CHARSET utf8;
USE migration_ds_0
CREATE TABLE t_order (order_id INT NOT NULL, user_id INT NOT NULL, status VARCHAR(45) NULL, PRIMARY KEY (order_id));
INSERT INTO t_order (order_id, user_id, status) VALUES (1,2,'ok'),(2,4,'ok'),(3,6,'ok'),(4,1,'ok'),(5,3,'ok'),(6,5,'ok');

1. Prepare the target database in openGauss.

DROP DATABASE IF EXISTS migration_ds_10;
CREATE DATABASE migration_ds_10;
DROP DATABASE IF EXISTS migration_ds_11;
CREATE DATABASE migration_ds_11;
DROP DATABASE IF EXISTS migration_ds_12;
CREATE DATABASE migration_ds_12;

Procedure

1. Create a new logical database and configure storage units and rules.

1.1. Create logic database.

CREATE DATABASE sharding_db;
\c sharding_db

1.2. Register storage units.

REGISTER STORAGE UNIT ds_2 (
    URL="jdbc:opengauss://127.0.0.1:5432/migration_ds_10",
    USER="gaussdb",
    PASSWORD="Root@123",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
), ds_3 (
    URL="jdbc:opengauss://127.0.0.1:5432/migration_ds_11",
    USER="gaussdb",
    PASSWORD="Root@123",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
), ds_4 (
    URL="jdbc:opengauss://127.0.0.1:5432/migration_ds_12",
    USER="gaussdb",
    PASSWORD="Root@123",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);

1.3. Create sharding table rule.

CREATE SHARDING TABLE RULE t_order(
STORAGE_UNITS(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"))
);

1.4. Create target table.

If you are migrating to a heterogeneous database, you need to execute the table-creation statements in proxy.

MySQL example:

CREATE TABLE t_order (order_id INT NOT NULL, user_id INT NOT NULL, status VARCHAR(45) NULL, PRIMARY KEY (order_id));

1. Configure the source storage units in proxy.

2.1. Isomorphic database.

REGISTER MIGRATION SOURCE STORAGE UNIT ds_0 (
    URL="jdbc:opengauss://127.0.0.1:5432/migration_ds_0",
    USER="gaussdb",
    PASSWORD="Root@123",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);

2.2. Heterogeneous database.

MySQL example:

REGISTER MIGRATION SOURCE STORAGE UNIT ds_0 (
    URL="jdbc:mysql://127.0.0.1:3306/migration_ds_0?serverTimezone=UTC&useSSL=false",
    USER="root",
    PASSWORD="root",
    PROPERTIES("minPoolSize"="1","maxPoolSize"="20","idleTimeout"="60000")
);

1. Enable data migration.

MIGRATE TABLE ds_0.t_order INTO t_order;

Or you can specify a target logical database.

MIGRATE TABLE ds_0.t_order INTO sharding_db.t_order;

Or you can specify a source schema name.

MIGRATE TABLE ds_0.public.t_order INTO sharding_db.t_order;

1. Check the data migration job list.

SHOW MIGRATION LIST;

Result example:

+---------------------------------------+---------+----------------------+--------+---------------------+-----------+
| id                                    | tables  | job_item_count       | active | create_time         | stop_time |
+---------------------------------------+---------+----------------------+--------+---------------------+-----------+
| j01016e501b498ed1bdb2c373a2e85e2529a6 | t_order | 1                    | true   | 2022-10-13 11:16:01 | NULL      |
+---------------------------------------+---------+----------------------+--------+---------------------+-----------+

1. View the data migration details.

SHOW MIGRATION STATUS 'j01016e501b498ed1bdb2c373a2e85e2529a6';

Result example:

+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+
| item | data_source | status                   | active | processed_records_count | inventory_finished_percentage | incremental_idle_seconds | error_message |
+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+
| 0    | ds_0        | EXECUTE_INCREMENTAL_TASK | true   | 6                       | 100                           | 81                       |               |
+------+-------------+--------------------------+--------+-------------------------+-------------------------------+--------------------------+---------------+

1. Verify data consistency.

CHECK MIGRATION 'j01016e501b498ed1bdb2c373a2e85e2529a6';
Query OK, 0 rows affected (0.09 sec)

Query data consistency check progress:

SHOW MIGRATION CHECK STATUS 'j01016e501b498ed1bdb2c373a2e85e2529a6';

Result example:

+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+
| tables  | result | finished_percentage | remaining_seconds | check_begin_time        | check_end_time          | duration_seconds | error_message |
+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+
| t_order | true   | 100                 | 0                 | 2022-10-13 11:18:15.171 | 2022-10-13 11:18:15.878 | 0                |               |
+---------+--------+---------------------+-------------------+-------------------------+-------------------------+------------------+---------------+

1. Commit the job.

COMMIT MIGRATION 'j01016e501b498ed1bdb2c373a2e85e2529a6';

1. Refresh table metadata.

REFRESH TABLE METADATA;

Please refer to RAL#Migration for more details.