DRS Pre-Check Items_Data Replication Service

Overview

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

The following lists the pre-check items for migration tasks with MySQL serving as the source.
The following lists the pre-check items for migration tasks with MySQL schema and logic table serving as the source.
- MySQL schema and logic table -> DDM
The following lists the pre-check items for migration tasks with MongoDB serving as the source.
- MongoDB->DDS
- MongoDB->GeminiDB Mongo
The following lists the pre-check items for migration tasks with DDS serving as the source.
- DDS->MongoDB

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?
Permissions	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.
	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 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.
Destination database	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?
Permissions	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.
Versions	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.
	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 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?
Permissions	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.
	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 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.
Destination database	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?
Permissions	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.
Versions	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.
Permissions	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.
	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.
	Duplicate names	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.
Permissions	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.
	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.
	Duplicate names	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.
Permissions	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.
	Duplicate names	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.

DRS Pre-Check Items

Overview

MySQL->MySQL

MySQL->DDM

MySQL->GaussDB(for MySQL)

MySQL schema and logic table -> DDM

MongoDB->DDS

MongoDB->GeminiDB Mongo

DDS->MongoDB

Feedback

Was this page helpful?