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.

The following lists the pre-check items for migration tasks with MySQL serving as the source.
- MySQL->MySQL
The following lists the pre-check items for migration tasks with MongoDB serving as the source.
- MongoDB->DDS
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
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.
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.
Versions	Source database versions	Versions 5.5, 5.6, 5.7, and 8.0 are supported.
	Destination database versions	Versions 5.5, 5.6, 5.7, and 8.0 are supported.
	Migration version	The destination database version must be the same as or later than the source database 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.
	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.
		The binlog_row_image parameter value of the source database must be FULL. Otherwise, the migration fails.
	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.
	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.
	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.
Incremental migration	Binlog status	The binlog of the source database must be enabled and the row-based format must be used during incremental migration.
	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 DRS User Guide.
	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.
	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.
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.
	Collation	The collation_server value of the destination database must be the same as that of the source database.
	Time zone	The time_zone value of the destination database must be the same as that of the source database.
	Case sensitive	The lower_case_table_names value of the destination database must be the same as that of the source database.
	Transaction isolation level	The transaction isolation level of the destination database must be the same as that of the source database.
	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.
	server_uuid parameter	The server_uuid values of the destination and source databases must be different.
	InnoDB check mode	The innodb_strict_mode value of the destination database must be the same as that of the source database.
	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.
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.
	Associated objects	Associated objects must be migrated at the same time to avoid migration failure caused by missing associated objects.
	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.
	Duplicate names	The destination DB instance cannot contain databases with the same name as the source databases (except the MySQL system database).
	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.

MongoDB->DDS

Table 2 Pre-check items
Category	Check Item	Check Item Details
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.
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.
Versions	Source database version	Versions 3.2, 3.4, 3.6, 4.0, 4.2, and 4.4 are supported.
	Destination database version	Versions 3.4, 4.0, 4.2, and 4.4 are supported.
	Migration version	The destination database version must be the same as or later than the source database 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.
	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.
Destination database	Storage space	The destination DB instance must have 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.
Consistency	Collections	Check whether collections in both the source and destination databases are not capped. If not, the migration fails.
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.
	Referenced accounts	If the roles referenced by accounts to be migrated are not migrated to the destination database, the migration may fail.
	Duplicate names	Destination database cannot contain non-empty collections with the same name as those in the source database.
	Duplicate names	Destination database cannot contain views with the same name as those in the source database.
	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.
	Composite hash shard keys
	Indexes	Check whether the _id fields in the collections of the source database have indexes. If not, the migration fails.
	TTL indexes	Due to inconsistency of time zones and clocks between source and destination databases, migrating TTL indexes will cause data inconsistency.
	The number of indexes	If the number of indexes in the source database exceeds 10, the migration duration is affected.

DDS->MongoDB

Table 3 Pre-check items
Category	Check Item	Check Item Details
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.
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.
Versions	Source database version	Versions 3.2, 3.4, 3.6, 4.0, 4.2, and 4.4 are supported.
	Destination database version	Versions 3.2, 3.4, 3.6, 4.0, 4.2, and 4.4 are supported.
	Migration version	The destination database version must be the same as or later than the source database 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.
	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.
Destination database	Storage space	The destination DB instance must have 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.
Consistency	Collections	Check whether collections in both the source and destination databases are not capped. If not, the migration fails.
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.
	Duplicate names	Destination database cannot contain views with the same name as those in the source database.
	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.

Parent topic: Appendix

Предыдущая статья

General Usage Suggestions

Следующая статья

Backup Migration

Была ли эта статья полезна?

Поддержка Юридические документы