Updated on 2024-05-09 GMT+08:00

DRS Pre-Check Items

A DRS migration process consists of four phases: task startup, full migration, incremental migration, and task completion. A single full migration task contains three phases. To ensure smooth migration, DRS automatically scans and checks parameters and objects in the source and destination databases before starting a migration task. The following table lists common check items.

Overview

View pre-check itmes based on the source database type of your migration task.

MySQL->MySQL

Table 1 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:

    SELECT, SHOW VIEW, and EVENT

  • Full+incremental migration requires the following minimum permissions:

    SELECT, SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE, and REPLICATION CLIENT

  • The user must have the SELECT permission for mysql.user if the source database is a non-Alibaba Cloud database. If the source database is an Alibaba Cloud database, the user must have the SELECT permission for mysql.user and mysql.user_view.

For details, see Which MySQL Permissions Are Required for DRS?

Destination database permissions

  • The destination database user must have the following permissions:

    SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, INDEX, EVENT, CREATE VIEW, CREATE ROUTINE, TRIGGER, REFERENCES, and WITH GRANT OPTION. If the destination database version is in the range 8.0.14 to 8.0.18, the SESSION_VARIABLES_ADMIN permission is required.

  • To migrate data, you must have the SELECT, INSERT, UPDATE, and DELETE permissions for the MySQL database.

For details, see Which MySQL Permissions Are Required for DRS?

Versions

Source database versions

Versions 5.5, 5.6, 5.7, and 8.0 are supported.

For details, see Supported Databases.

Destination database versions

Versions 5.5, 5.6, 5.7, and 8.0 are supported.

For details, see Supported Databases.

Migration version

The destination database version must be the same as or later than the source database version.

For details, see Checking Whether the Migration Is from an Earlier Database Version to the Same or a Later Version.

Parameters

GTID status

Enable GTID for the source database. If GTID is not enabled for the source database, primary/standby switchover is not supported. DRS tasks will be interrupted and cannot be restored during a switchover.

For details, see Checking Whether GTID Is Enabled for the Source Database.

Performance parameters

Enable skip-name-resolve for the source database to reduce the possibility of connection timeout.

-

The log_slave_updates parameter of the source database must be enabled. Otherwise, the migration fails.

For details, see Checking Whether the log_slave_updates Value of the Source Database Is Correctly Configured.

The binlog_row_image parameter value of the source database must be FULL. Otherwise, the migration fails.

For details, see Checking Whether the binlog_row_image Value is FULL.

Maximum size of a packet that can be transmitted

If there is a lot of data to be migrated or there are too many fields to be migrated, and the max_allowed_packet value of the source database is too small, the migration task may fail.

For details, see Whether the max_allowed_packet Value of the Source Database Is Too Small.

If there is a lot of data to be migrated or there are too many fields to be migrated, and the max_allowed_packet value of the destination database is too small, data cannot be written to the destination database and the full migration fails.

For details, see Checking Whether the max_allowed_packet Value of the Destination Database Is too Small.

sql_mode value

If the MyISAM tables are included in the migration objects, the sql_mode value in the destination database cannot be no_engine_substitution. Otherwise, the migration fails.

For details, see Checking Whether the Source Database Contains Invalid sql_mode Values.

Incremental migration

Binlog status

The binlog of the source database must be enabled and the row-based format must be used during incremental migration.

For details, see Checking Whether the Source Database Binlog Is Enabled.

Binlog retention period

If the storage space is sufficient, store the source database binlog files as long as possible. The recommended retention period is three days. If you set the period to 0, the migration may fail.

  • If the source database is a self-managed MySQL database, set expire_logs_days to specify the binlog retention period. Set expire_logs_day to a proper value to ensure that the binlog does not expire before data transfer resumes. This ensures that services can be recovered after interruption.
  • If the source database is RDS for MySQL, set the binlog retention period by following the instructions provided in Setting a Local Retention Period for RDS for MySQL Binlogs.

For details, see Checking Whether the Binlog Retention Period Is Set on the Source Database.

server_id value

During an incremental migration, the server_id value of the MySQL source database must be set.

  • If the source database version is MySQL 5.6 or earlier, the value of server_id ranges from 2 to 4294967296.
  • If the source database version is MySQL 5.7 or later, the value of server_id ranges from 1 to 4294967296.

For details, see Checking Whether the Source Database server_id Meets the Incremental Migration Requirements.

Session variables

During an incremental migration, if the session variable character_set_client is set to binary, some data may include garbled characters.

-

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

Status

The destination DB instance is running properly.

-

Consistency

Character set

The character set of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Character Sets Are Consistent.

Collation

The collation_server value of the destination database must be the same as that of the source database.

For details, see Checking Whether the COLLATION_SERVER Values of the Source and Destination Databases Are the Same.

Time zone

The time_zone value of the destination database must be the same as that of the source database.

For details, see Checking Whether the TIME_ZONE Values of the Source and Destination Databases Are the Same.

Case sensitive

The lower_case_table_names value of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Table Names Are Consistent in Case Sensitivity.

Transaction isolation level

The transaction isolation level of the destination database must be the same as that of the source database.

For details, see Checking Whether the Transaction Isolation Levels are Consistent.

Maximum length of the calculation result of the group_concat function

The group_concat_max_len value of the destination database must be the same as that of the source database.

For details, see Checking Whether the Values of group_concat_max_len Are Consistent.

server_uuid parameter

The server_uuid values of the destination and source databases must be different.

For details, see Checking Whether the SERVER_UUID Values of the Source and Destination Databases Are the Same.

InnoDB check mode

The innodb_strict_mode value of the destination database must be the same as that of the source database.

For details, see Checking Whether the innodb_strict_mode Values of the Source and Destination Databases Are the Same.

Data block encryption parameter

The block_encryption_mode value of the destination database must be the same as that of the source database.

-

SQL mode

The sql_mode value of the destination database must be the same as that of the source database.

For details, see Checking Whether the sql_mode Values of the Source and Destination Databases Are the Same.

Migration objects

Selected objects

  • Databases, tables, users, views, indexes, constraints, functions, stored procedures, triggers, and events can be migrated.
  • Only MyISAM and InnoDB tables can be migrated.
  • The system database and event statuses cannot be migrated.

-

Tables without primary keys

Create primary keys for tables as the performance of a table without a primary key is lower than that of a table with a primary key.

For details, see Checking Whether the Source Database Tables Contain Primary Keys.

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

For details, see Checking Whether Referenced Tables Are Selected for Migration.

Foreign key reference operations

Cascade operations cannot be performed on tables with foreign keys. If the foreign key index of a table is a common index, the table structure may fail to be created. You are advised to use a unique index.

For details, see Whether There Are Foreign Keys Containing Unsupported Reference Operations in the Source Database.

Duplicate names

The destination DB instance cannot contain databases with the same name as the source databases (except the MySQL system database).

For details, see Checking Whether the Names of the Source and Destination Databases Are the Same.

Table naming rules

  • The source database name, table name, and view name cannot contain non-ASCII characters or special characters '<>`/\"
  • The source database name cannot start with ib_logfile and cannot be ib_buffer_pool, ib_doublewrite, ibdata1 or ibtmp1.

-

Encrypted table check

If there are encrypted tables in the source database, check whether these tables are supported on the destination database. If the destination database does not support these tables, the task may fail.

For details, see Source Encrypted Table Check.

MySQL->DDM

Table 2 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:

    SELECT, SHOW VIEW, and EVENT

  • Full+incremental migration requires the following minimum permissions:

    SELECT, SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE, and REPLICATION CLIENT

For details, see Which MySQL Permissions Are Required for DRS?

Destination database permissions

  • The DDM destination database user must have the following permissions: CREATE, DROP, ALTER, INDEX, INSERT, DELETE, UPDATE, and SELECT. In addition, grant the SELECT permission on all tables.
  • The DDM destination database user must have the permission on the database to be migrated.

For details, see Creating an Account.

Versions

Source database versions

Versions 5.5, 5.6, 5.7, and 8.0 are supported.

For details, see Supported Databases.

Destination database version

DDM instance version.

For details, see Supported Databases.

Parameters

GTID status

Enable GTID for the source database. If GTID is not enabled for the source database, primary/standby switchover is not supported. DRS tasks will be interrupted and cannot be restored during a switchover.

For details, see Checking Whether GTID Is Enabled for the Source Database.

Performance parameters

Enable skip-name-resolve for the source database to reduce the possibility of connection timeout.

-

The log_slave_updates parameter of the source database must be enabled. Otherwise, the migration fails.

For details, see Checking Whether the log_slave_updates Value of the Source Database Is Correctly Configured.

The binlog_row_image parameter value of the source database must be FULL. Otherwise, the migration fails.

For details, see Checking Whether the binlog_row_image Value is FULL.

Maximum size of a packet that can be transmitted

If there is a lot of data to be migrated or there are too many fields to be migrated, and the max_allowed_packet value of the source database is too small, the migration task may fail.

For details, see Whether the max_allowed_packet Value of the Source Database Is Too Small.

If there is a lot of data to be migrated or there are too many fields to be migrated, and the max_allowed_packet value of the destination database is too small, data cannot be written to the destination database and the full migration fails.

For details, see Checking Whether the max_allowed_packet Value of the Destination Database Is too Small.

sql_mode value

If the MyISAM tables are included in the migration objects, the sql_mode value in the destination database cannot be no_engine_substitution. Otherwise, the migration fails.

For details, see Checking Whether the Source Database Contains Invalid sql_mode Values.

Incremental migration

Binlog status

The binlog of the source database must be enabled and the row-based format must be used during incremental migration.

For details, see Checking Whether the Source Database Binlog Is Enabled.

Binlog retention period

If the storage space is sufficient, store the source database binlog files as long as possible. The recommended retention period is three days. If you set the period to 0, the migration may fail.

  • If the source database is a self-managed MySQL database, set expire_logs_days to specify the binlog retention period. Set expire_logs_day to a proper value to ensure that the binlog does not expire before data transfer resumes. This ensures that services can be recovered after interruption.
  • If the source database is RDS for MySQL, set the binlog retention period by following the instructions provided in Setting a Local Retention Period for RDS for MySQL Binlogs.

For details, see Checking Whether the Binlog Retention Period Is Set on the Source Database.

server_id value

During an incremental migration, the server_id value of the MySQL source database must be set.

  • If the source database version is MySQL 5.6 or earlier, the value of server_id ranges from 2 to 4294967296.
  • If the source database version is MySQL 5.7 or later, the value of server_id ranges from 1 to 4294967296.

For details, see Checking Whether the Source Database server_id Meets the Incremental Migration Requirements.

Session variables

During an incremental migration, if the session variable character_set_client is set to binary, some data may include garbled characters.

-

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

Status

The destination DB instance is running properly.

-

auto_increment parameter

The auto_increment value of a table in the destination cannot be less than that of a table in the source.

-

Consistency

Character set

The character set of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Character Sets Are Consistent.

Collation

The collation_server value of the destination database must be the same as that of the source database.

For details, see Checking Whether the COLLATION_SERVER Values of the Source and Destination Databases Are the Same.

Time zone

The time_zone value of the destination database must be the same as that of the source database.

For details, see Checking Whether the TIME_ZONE Values of the Source and Destination Databases Are the Same.

Case sensitive

The lower_case_table_names value of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Table Names Are Consistent in Case Sensitivity.

Transaction isolation level

The transaction isolation level of the destination database must be the same as that of the source database.

For details, see Checking Whether the Transaction Isolation Levels are Consistent.

Maximum length of the calculation result of the group_concat function

The group_concat_max_len value of the destination database must be the same as that of the source database.

For details, see Checking Whether the Values of group_concat_max_len Are Consistent.

server_uuid parameter

The server_uuid values of the destination and source databases must be different.

For details, see Checking Whether the SERVER_UUID Values of the Source and Destination Databases Are the Same.

InnoDB check mode

The innodb_strict_mode value of the destination database must be the same as that of the source database.

For details, see Checking Whether the innodb_strict_mode Values of the Source and Destination Databases Are the Same.

Data block encryption parameter

The block_encryption_mode value of the destination database must be the same as that of the source database.

-

SQL mode

The sql_mode value of the destination database must be the same as that of the source database.

For details, see Checking Whether the sql_mode Values of the Source and Destination Databases Are the Same.

Table structures

  • To migrate table structures and other objects, you need to create table structures and indexes in the destination database based on table structures of the source schema. Any source objects that have no corresponding objects created in the destination cannot be migrated.
  • The table structure created in the destination database must be the same as that in the source database.

-

Migration objects

Selected objects

  • Only the source database data can be migrated. The table structure and other database objects of the source database cannot be migrated.
  • Only MyISAM and InnoDB tables can be migrated.
  • The system database and event statuses cannot be migrated.
  • If the source database is MySQL 8.0, tables with function indexes cannot be migrated.

-

Tables without primary keys

Create primary keys for tables as the performance of a table without a primary key is lower than that of a table with a primary key.

For details, see Checking Whether the Source Database Tables Contain Primary Keys.

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

For details, see Checking Whether Referenced Tables Are Selected for Migration.

Foreign key reference operations

Cascade operations cannot be performed on tables with foreign keys. If the foreign key index of a table is a common index, the table structure may fail to be created. You are advised to use a unique index.

For details, see Whether There Are Foreign Keys Containing Unsupported Reference Operations in the Source Database.

Table naming rules

  • The names of the source databases and tables cannot contain non-ASCII characters, or special characters <'>`/\"
  • The source database name cannot start with ib_logfile and cannot be ib_buffer_pool, ib_doublewrite, ibdata1 or ibtmp1.

-

Encrypted table check

If there are encrypted tables in the source database, check whether these tables are supported on the destination database. If the destination database does not support these tables, the task may fail.

For details, see Source Encrypted Table Check.

MySQL->GaussDB(for MySQL)

Table 3 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:

    SELECT, SHOW VIEW, and EVENT

  • Full+incremental migration requires the following minimum permissions:

    SELECT, SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE, and REPLICATION CLIENT

  • The user must have the SELECT permission for mysql.user if the source database is a non-Alibaba Cloud database. If the source database is an Alibaba Cloud database, the user must have the SELECT permission for mysql.user and mysql.user_view.

For details, see Which MySQL Permissions Are Required for DRS?

Destination database permissions

  • The destination database user must have the following permissions:

    SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, INDEX, EVENT, CREATE VIEW, CREATE ROUTINE, TRIGGER, REFERENCES, and WITH GRANT OPTION. If the destination database version is in the range 8.0.14 to 8.0.18, the SESSION_VARIABLES_ADMIN permission is required.

  • To migrate data, you must have the SELECT, INSERT, UPDATE, and DELETE permissions for the MySQL database.

For details, see Which MySQL Permissions Are Required for DRS?

Versions

Source database versions

Versions 5.5, 5.6, 5.7, and 8.0 are supported.

For details, see Supported Databases.

Destination database version

GaussDB(for MySQL) 8.0 is supported.

For details, see Supported Databases.

Migration version

The destination database version must be the same as or later than the source database version.

For details, see Checking Whether the Migration Is from an Earlier Database Version to the Same or a Later Version.

Parameters

GTID status

Enable GTID for the source database. If GTID is not enabled for the source database, primary/standby switchover is not supported. DRS tasks will be interrupted and cannot be restored during a switchover.

For details, see Checking Whether GTID Is Enabled for the Source Database.

Performance parameters

Enable skip-name-resolve for the source database to reduce the possibility of connection timeout.

-

The log_slave_updates parameter of the source database must be enabled. Otherwise, the migration fails.

For details, see Checking Whether the log_slave_updates Value of the Source Database Is Correctly Configured.

The binlog_row_image parameter value of the source database must be FULL. Otherwise, the migration fails.

For details, see Checking Whether the binlog_row_image Value is FULL.

Maximum size of a packet that can be transmitted

If there is a lot of data to be migrated or there are too many fields to be migrated, and the max_allowed_packet value of the source database is too small, the migration task may fail.

For details, see Whether the max_allowed_packet Value of the Source Database Is Too Small.

If there is a lot of data to be migrated or there are too many fields to be migrated, and the max_allowed_packet value of the destination database is too small, data cannot be written to the destination database and the full migration fails.

For details, see Checking Whether the max_allowed_packet Value of the Destination Database Is too Small.

sql_mode value

If the MyISAM tables are included in the migration objects, the sql_mode value in the destination database cannot be no_engine_substitution. Otherwise, the migration fails.

For details, see Checking Whether the Source Database Contains Invalid sql_mode Values.

Incremental migration

Binlog status

The binlog of the source database must be enabled and the row-based format must be used during incremental migration.

For details, see Checking Whether the Source Database Binlog Is Enabled.

Binlog retention period

If the storage space is sufficient, store the source database binlog files as long as possible. The recommended retention period is three days. If you set the period to 0, the migration may fail.

  • If the source database is a self-managed MySQL database, set expire_logs_days to specify the binlog retention period. Set expire_logs_day to a proper value to ensure that the binlog does not expire before data transfer resumes. This ensures that services can be recovered after interruption.
  • If the source database is RDS for MySQL, set the binlog retention period by following the instructions provided in Setting a Local Retention Period for RDS for MySQL Binlogs.

For details, see Checking Whether the Binlog Retention Period Is Set on the Source Database.

server_id value

During an incremental migration, the server_id value of the MySQL source database must be set.

  • If the source database version is MySQL 5.6 or earlier, the value of server_id ranges from 2 to 4294967296.
  • If the source database version is MySQL 5.7 or later, the value of server_id ranges from 1 to 4294967296.

For details, see Checking Whether the Source Database server_id Meets the Incremental Migration Requirements.

Session variables

During an incremental migration, if the session variable character_set_client is set to binary, some data may include garbled characters.

-

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

Status

The destination DB instance is running properly.

-

Consistency

Character set

The character set of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Character Sets Are Consistent.

Collation

The collation_server value of the destination database must be the same as that of the source database.

For details, see Checking Whether the COLLATION_SERVER Values of the Source and Destination Databases Are the Same.

Time zone

The time_zone value of the destination database must be the same as that of the source database.

For details, see Checking Whether the TIME_ZONE Values of the Source and Destination Databases Are the Same.

Case sensitive

The lower_case_table_names value of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Table Names Are Consistent in Case Sensitivity.

Transaction isolation level

The transaction isolation level of the destination database must be the same as that of the source database.

For details, see Checking Whether the Transaction Isolation Levels are Consistent.

Maximum length of the calculation result of the group_concat function

The group_concat_max_len value of the destination database must be the same as that of the source database.

For details, see Checking Whether the Values of group_concat_max_len Are Consistent.

server_uuid parameter

The server_uuid values of the destination and source databases must be different.

For details, see Checking Whether the SERVER_UUID Values of the Source and Destination Databases Are the Same.

InnoDB check mode

The innodb_strict_mode value of the destination database must be the same as that of the source database.

For details, see Checking Whether the innodb_strict_mode Values of the Source and Destination Databases Are the Same.

Data block encryption parameter

The block_encryption_mode value of the destination database must be the same as that of the source database.

-

SQL mode

The sql_mode value of the destination database must be the same as that of the source database.

For details, see Checking Whether the sql_mode Values of the Source and Destination Databases Are the Same.

Migration objects

Selected objects

  • Databases, tables, users, views, indexes, constraints, functions, stored procedures, triggers, and events can be migrated.
  • Only MyISAM and InnoDB tables can be migrated.
  • The system database and event statuses cannot be migrated.

-

Tables without primary keys

Create primary keys for tables as the performance of a table without a primary key is lower than that of a table with a primary key.

For details, see Checking Whether the Source Database Tables Contain Primary Keys.

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

For details, see Checking Whether Referenced Tables Are Selected for Migration.

Foreign key reference operations

Cascade operations cannot be performed on tables with foreign keys. If the foreign key index of a table is a common index, the table structure may fail to be created. You are advised to use a unique index.

For details, see Whether There Are Foreign Keys Containing Unsupported Reference Operations in the Source Database.

Duplicate names

The destination DB instance cannot contain databases with the same name as the source databases (except the MySQL system database).

For details, see Checking Whether the Names of the Source and Destination Databases Are the Same.

Table naming rules

  • The source database name, table name, and view name cannot contain non-ASCII characters or special characters '<>`/\"
  • The source database name cannot start with ib_logfile and cannot be ib_buffer_pool, ib_doublewrite, ibdata1 or ibtmp1.

-

Encrypted table check

If there are encrypted tables in the source database, check whether these tables are supported on the destination database. If the destination database does not support these tables, the task may fail.

For details, see Source Encrypted Table Check.

MySQL schema and logic table -> DDM

Table 4 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:

    SELECT, SHOW VIEW, and EVENT

  • Full+incremental migration requires the following minimum permissions:

    SELECT, SHOW VIEW, EVENT, LOCK TABLES, REPLICATION SLAVE, and REPLICATION CLIENT

For details, see Which MySQL Permissions Are Required for DRS?

Destination database permissions

  • The DDM destination database user must have the following permissions: CREATE, DROP, ALTER, INDEX, INSERT, DELETE, UPDATE, and SELECT. In addition, grant the SELECT permission on all tables.
  • The DDM destination database user must have the permission on the database to be migrated.

For details, see Creating an Account.

Versions

Source database version

DDM instance version.

For details, see Supported Databases.

Destination database version

DDM instance version.

For details, see Supported Databases.

Parameters

GTID status

Enable GTID for the source database. If GTID is not enabled for the source database, primary/standby switchover is not supported. DRS tasks will be interrupted and cannot be restored during a switchover.

For details, see Checking Whether GTID Is Enabled for the Source Database.

Performance parameters

Enable skip-name-resolve for the source database to reduce the possibility of connection timeout.

-

The log_slave_updates parameter of the source database must be enabled. Otherwise, the migration fails.

For details, see Checking Whether the log_slave_updates Value of the Source Database Is Correctly Configured.

The binlog_row_image parameter value of the source database must be FULL. Otherwise, the migration fails.

For details, see Checking Whether the binlog_row_image Value is FULL.

Incremental migration

Binlog status

The binlog of the source database must be enabled and the row-based format must be used during incremental migration.

For details, see Checking Whether the Source Database Binlog Is Enabled.

Binlog retention period

If the storage space is sufficient, store the source database binlog files as long as possible. The recommended retention period is three days. If you set the period to 0, the migration may fail.

  • If the source database is a self-managed MySQL database, set expire_logs_days to specify the binlog retention period. Set expire_logs_day to a proper value to ensure that the binlog does not expire before data transfer resumes. This ensures that services can be recovered after interruption.
  • If the source database is RDS for MySQL, set the binlog retention period by following the instructions provided in Setting a Local Retention Period for RDS for MySQL Binlogs.

For details, see Checking Whether the Binlog Retention Period Is Set on the Source Database.

server_id value

During an incremental migration, the server_id value of the MySQL source database must be set.

  • If the source database version is MySQL 5.6 or earlier, the value of server_id ranges from 2 to 4294967296.
  • If the source database version is MySQL 5.7 or later, the value of server_id ranges from 1 to 4294967296.

For details, see Checking Whether the Source Database server_id Meets the Incremental Migration Requirements.

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

Status

The destination DB instance is running properly.

-

auto_increment parameter

The auto_increment value of a table in the destination cannot be less than that of a table in the source.

-

Consistency

Character set

The character set of the destination database must be the same as that of the source database.

For details, see Checking Whether the Source and Destination Database Character Sets Are Consistent.

Collation

The collation_server value of the destination database must be the same as that of the source database.

For details, see Checking Whether the COLLATION_SERVER Values of the Source and Destination Databases Are the Same.

Table structures

  • To migrate table structures and other objects, you need to create table structures and indexes in the destination database based on table structures of the source schema. Any source objects that have no corresponding objects created in the destination cannot be migrated.
  • The table structure created in the destination database must be the same as that in the source database.

-

Migration objects

Selected objects

  • Only the source database data can be migrated. The table structure and other database objects of the source database cannot be migrated.
  • Only MyISAM and InnoDB tables can be migrated.
  • The system database and event statuses cannot be migrated.
  • If the source database is MySQL 8.0, tables with function indexes cannot be migrated.

-

Tables without primary keys

Create primary keys for tables as the performance of a table without a primary key is lower than that of a table with a primary key.

For details, see Checking Whether the Source Database Tables Contain Primary Keys.

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

For details, see Checking Whether Referenced Tables Are Selected for Migration.

Foreign key reference operations

Cascade operations cannot be performed on tables with foreign keys. If the foreign key index of a table is a common index, the table structure may fail to be created. You are advised to use a unique index.

For details, see Whether There Are Foreign Keys Containing Unsupported Reference Operations in the Source Database.

Destination database objects

Ensure that the destination database is empty before starting the migration. Otherwise, data in the destination may be overwritten during incremental migration.

-

Table naming rules

  • The names of the source databases and tables cannot contain non-ASCII characters, or special characters <'>`/\"
  • The source database name cannot start with ib_logfile and cannot be ib_buffer_pool, ib_doublewrite, ibdata1 or ibtmp1.

-

MongoDB->DDS

Table 5 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:
    • Replica set: The source database user must have the readAnyDatabase permission for the admin database.
    • Single node: The source database user must have the readAnyDatabase permission for the admin database.
    • Cluster: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the config database.
    • To migrate accounts and roles of the source database, the source and destination database users must have the read permission for the system.users and system.roles system tables of the admin database.
  • Full+incremental migration requires the following minimum permissions:
    • Replica set: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • Single node: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • Cluster: The source mongos node user must have the readAnyDatabase permission for the admin database and the read permission for the config database. The source shard node user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • To migrate accounts and roles of the source database, the source and destination database users must have the read permission for the system.users and system.roles system tables of the admin database.

For details, see MongoDB Migration and Synchronization.

Destination database permissions

The destination database user must have the dbAdminAnyDatabase permission for the admin database and the readWrite permission for the destination database.

If the destination database is a cluster instance, the database user must have the clusterManager permission for the admin database.

For details, see DDS Migration and Synchronization.

Versions

Source database version

Versions 3.2, 3.4, 3.6, 4.0, 4.2, and 4.4 are supported.

For details, see Supported Databases.

Destination database version

Versions 3.4, 4.0, 4.2, and 4.4 are supported.

For details, see Supported Databases.

Migration version

The destination database version must be the same as or later than the source database version.

For details, see Checking Whether the Migration Is from an Earlier Database Version to the Same or a Later Version.

Incremental migration

Oplog status

During an incremental migration, Oplog of the source database must be enabled.

-

Oplog retention period

If the storage space is sufficient, store the source database Oplog for as long as possible. The recommended retention period is three days.

-

Balancer status

If the incremental source data cluster is migrated, the source database balancer must be disabled.

For details, see How Do I Disable the Balancer?

Orphaned documents

If the full+incremental data needs to be migrated from the source cluster database, the balancer of the source database must be disabled and orphaned documents must be deleted.

For details, see How Do I Delete Orphaned Documents in MongoDB Sharded Clusters?

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

DRS supports full migration between cluster instances. If the source cluster instance is not sharded, ensure that the size of the primary shard on the destination database is greater than that of the source database.

Status

The destination DB instance is running properly.

-

Maximum number of chunks

Check whether the maximum number of chunks in the destination database is sufficient to support sharding and splitting of the source database. If the maximum number of chunks is reached, chunks are not split and the write performance is negatively affected.

For details, see Checking Whether the Maximum Number of Chunks in the Destination Database Is Sufficient.

Consistency

Collections

Check whether collections in both the source and destination databases are not capped. If not, the migration fails.

For details, see Checking Whether Collections in Both the Source and Destination Databases Are Not Capped.

Migration objects

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

-

Referenced roles

If the roles referenced by accounts to be migrated are not migrated to the destination database, the migration may fail.

For details, see Checking Whether the Source Database Referenced Roles Pass the Check.

Referenced accounts

If the roles referenced by accounts to be migrated are not migrated to the destination database, the migration may fail.

For details, see Checking Whether the Source Database Referenced Accounts Pass the Check.

Duplicate names

Destination database cannot contain non-empty collections with the same name as those in the source database.

For details, see Checking Whether the Destination Database Contains a Non-Empty Collection with the Same Name As the Source Database.

Destination database cannot contain views with the same name as those in the source database.

For details, see Checking Whether the Same View Names Exist in Both the Source and Destination Databases.

Naming rules

The source database name cannot contain /\."$ or spaces. The collection name and view name cannot start with system. or contain the dollar sign ($).

-

Composite hash indexes

  • If the source is a cluster instance of version 4.4, composite hash indexes and composite hash shard keys are not supported.
  • If the source is a replica set instance of version 4.4, composite hash indexes are not supported.

For details, see Whether There Are Composite Hash Indexes in the Source Collection.

Composite hash shard keys

For details, see Whether There Are Composite Hash Shard Keys in the Source Collection.

Indexes

Check whether the _id fields in the collections of the source database have indexes. If not, the migration fails.

For details, see Checking Whether the _Id Fields in the Collection of the Source Database Have Indexes.

TTL indexes

Due to inconsistency of time zones and clocks between source and destination databases, migrating TTL indexes will cause data inconsistency.

For details, see Checking Whether the Source Database Collections Contain TTL Indexes.

The number of indexes

If the number of indexes in the source database exceeds 10, the migration duration is affected.

For details, see Checking Whether the Source Database Collections Contain More Than 10 Indexes.

MongoDB->GeminiDB Mongo

Table 6 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:
    • Replica set: The source database user must have the readAnyDatabase permission for the admin database.
    • Single node: The source database user must have the readAnyDatabase permission for the admin database.
    • Cluster: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the config database.
    • To migrate accounts and roles of the source database, the source and destination database users must have the read permission for the system.users and system.roles system tables of the admin database.
  • Full+incremental migration requires the following minimum permissions:
    • Replica set: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • Single node: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • Cluster: The source mongos node user must have the readAnyDatabase permission for the admin database and the read permission for the config database. The source shard node user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • To migrate accounts and roles of the source database, the source and destination database users must have the read permission for the system.users and system.roles system tables of the admin database.

For details, see MongoDB Migration and Synchronization.

Destination database permissions

The destination database user must have the dbAdminAnyDatabase permission for the admin database and the readWrite permission for the destination database.

If the destination database is a cluster instance, the database user must have the clusterManager permission for the admin database.

For details, see MongoDB Migration and Synchronization.

Versions

Source database version

Versions 3.2, 3.4, 4.0, and 4.2 are supported.

For details, see Supported Databases.

Destination database version

Versions 3.4 and 4.0 are supported.

For details, see Supported Databases.

Migration version

The destination database version must be the same as or later than the source database version.

For details, see Checking Whether the Migration Is from an Earlier Database Version to the Same or a Later Version.

Incremental migration

Oplog status

During an incremental migration, Oplog of the source database must be enabled.

-

Oplog retention period

If the storage space is sufficient, store the source database Oplog for as long as possible. The recommended retention period is three days.

-

Balancer status

If the incremental source data cluster is migrated, the source database balancer must be disabled.

For details, see How Do I Disable the Balancer?

Orphaned documents

If the full+incremental data needs to be migrated from the source cluster database, the balancer of the source database must be disabled and orphaned documents must be deleted.

For details, see How Do I Delete Orphaned Documents in MongoDB Sharded Clusters?

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

DRS supports full migration between cluster instances. If the source cluster instance is not sharded, ensure that the size of the primary shard on the destination database is greater than that of the source database.

Status

The destination DB instance is running properly.

-

Maximum number of chunks

Check whether the maximum number of chunks in the destination database is sufficient to support sharding and splitting of the source database. If the maximum number of chunks is reached, chunks are not split and the write performance is negatively affected.

For details, see Checking Whether the Maximum Number of Chunks in the Destination Database Is Sufficient.

Consistency

Collections

Check whether collections in both the source and destination databases are not capped. If not, the migration fails.

For details, see Checking Whether Collections in Both the Source and Destination Databases Are Not Capped.

Migration objects

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

-

Referenced roles

If the roles referenced by accounts to be migrated are not migrated to the destination database, the migration may fail.

For details, see Checking Whether the Source Database Referenced Roles Pass the Check.

Referenced accounts

If the roles referenced by accounts to be migrated are not migrated to the destination database, the migration may fail.

For details, see Checking Whether the Source Database Referenced Accounts Pass the Check.

Duplicate names

Destination database cannot contain non-empty collections with the same name as those in the source database.

For details, see Checking Whether the Destination Database Contains a Non-Empty Collection with the Same Name As the Source Database.

Destination database cannot contain views with the same name as those in the source database.

For details, see Checking Whether the Same View Names Exist in Both the Source and Destination Databases.

Naming rules

The source database name cannot contain /\."$ or spaces. The collection name and view name cannot start with system. or contain the dollar sign ($).

-

Indexes

Check whether the _id fields in the collections of the source database have indexes. If not, the migration fails.

For details, see Checking Whether the _Id Fields in the Collection of the Source Database Have Indexes.

TTL indexes

Due to inconsistency of time zones and clocks between source and destination databases, migrating TTL indexes will cause data inconsistency.

For details, see Checking Whether the Source Database Collections Contain TTL Indexes.

The number of indexes

If the number of indexes in the source database exceeds 10, the migration duration is affected.

For details, see Checking Whether the Source Database Collections Contain More Than 10 Indexes.

DDS->MongoDB

Table 7 Pre-check items

Category

Check Item

Check Item Details

Solution to Failure

Permissions

Source database permissions

  • Full migration requires the following minimum permissions:
    • Replica set: The source database user must have the readAnyDatabase permission for the admin database.
    • Single node: The source database user must have the readAnyDatabase permission for the admin database.
    • Cluster: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the config database.
  • Full+incremental migration requires the following minimum permissions:
    • Replica set: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • Single node: The source database user must have the readAnyDatabase permission for the admin database and the read permission for the local database.
    • Cluster: The source mongos node user must have the readAnyDatabase permission for the admin database and the read permission for the config database. The source shard node user must have the readAnyDatabase permission for the admin database and the read permission for the local database.

For details, see DDS Migration and Synchronization.

Destination database permissions

The destination database user must have the dbAdminAnyDatabase permission for the admin database and the readWrite permission for the destination database.

If the destination database is a cluster instance, the database user must have the clusterManager permission for the admin database.

For details, see MongoDB Migration and Synchronization.

Versions

Source database version

Versions 3.2, 3.4, 3.6, 4.0, 4.2, and 4.4 are supported.

For details, see Supported Databases.

Destination database version

Versions 3.2, 3.4, 3.6, 4.0, 4.2, and 4.4 are supported.

For details, see Supported Databases.

Migration version

The destination database version must be the same as or later than the source database version.

For details, see Checking Whether the Migration Is from an Earlier Database Version to the Same or a Later Version.

Incremental migration

Oplog status

During an incremental migration, Oplog of the source database must be enabled.

-

Oplog retention period

If the storage space is sufficient, store the source database Oplog for as long as possible. The recommended retention period is three days.

-

Balancer status

If the incremental source data cluster is migrated, the source database balancer must be disabled.

For details, see How Do I Disable the Balancer?

Orphaned documents

If the full+incremental data needs to be migrated from the source cluster database, the balancer of the source database must be disabled and orphaned documents must be deleted.

For details, see How Do I Delete Orphaned Documents in MongoDB Sharded Clusters?

Destination database

Storage space

The destination DB instance must have sufficient storage space.

For details, see Checking Whether the Destination Database Has Sufficient Storage Space.

Status

The destination DB instance is running properly.

-

Maximum number of chunks

Check whether the maximum number of chunks in the destination database is sufficient to support sharding and splitting of the source database. If the maximum number of chunks is reached, chunks are not split and the write performance is negatively affected.

For details, see Checking Whether the Maximum Number of Chunks in the Destination Database Is Sufficient.

Consistency

Collections

Check whether collections in both the source and destination databases are not capped. If not, the migration fails.

For details, see Checking Whether Collections in Both the Source and Destination Databases Are Not Capped.

Migration objects

Associated objects

Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.

-

Duplicate names

Destination database cannot contain non-empty collections with the same name as those in the source database.

For details, see Checking Whether the Destination Database Contains a Non-Empty Collection with the Same Name As the Source Database.

Destination database cannot contain views with the same name as those in the source database.

For details, see Checking Whether the Same View Names Exist in Both the Source and Destination Databases.

Naming rules

The source database name cannot contain /\."$ or spaces. The collection name and view name cannot start with system. or contain the dollar sign ($).

-

The number of indexes

If the number of indexes in the source database exceeds 10, the migration duration is affected.

For details, see Checking Whether the Source Database Collections Contain More Than 10 Indexes.