You can use Data Transmission Service (DTS) to migrate data from a self-managed Redis database that is deployed in an on-premises data center, on an Elastic Compute Service (ECS) instance, or on a third-party cloud platform to ApsaraDB for Redis without affecting your business. DTS enables you to migrate data from an existing Redis database to ApsaraDB for Redis without interrupting the database service. DTS supports full and incremental data migration. DTS provides higher performance and security than the append-only file (AOF) method.
Overview
Full data migration
DTS allows you to migrate all existing data from a source database to a destination database free of charge.
Incremental data migration
After you perform full data migration, DTS can synchronize incremental data from the source database to the destination database in real time. To perform incremental data migration, you must run the
PSYNC
orSYNC
command in the source database. Otherwise, you can perform only full data migration. You are charged for incremental data migration based on the duration of the migration instead of the amount of data that is transferred. For more information, see Billable items.NoteTo ensure that incremental data migration tasks run as expected, we recommend that you remove the limit on the replication output buffer for the source database. To remove the limit, connect to the source database and run the following command:
CONFIG SET client-output-buffer-limit 'slave 0 0 0'
.
Prerequisites
An ApsaraDB for Redis instance is created, and the amount of memory allocated to the instance is larger than the amount of memory used by the self-managed Redis database. For more information, see Step 1: Create an ApsaraDB for Redis instance.
We recommend that you keep the total amount of memory of the destination database at least 10% larger than the amount of memory used by the source database. If the amount of memory of the destination database is insufficient when you run the data migration task, issues such as data inconsistency or task failures may occur. In this case, empty the destination database and reconfigure the data migration task.
Usage notes
When you run a data migration task, do not scale or change the specifications or endpoint of the source or destination database. Otherwise, the data migration task fails. If the data migration task fails, reconfigure the task to account for the changes. In addition, the data migration consumes resources of the source and destination databases. We recommend that you perform the data migration during off-peak hours.
Procedure
Go to the Data Migration Tasks page.
Log on to the Data Management (DMS) console.
In the top navigation bar, click DTS.
In the left-side navigation pane, choose .
Click Create Task.
Configure the source and destination databases and click Test Connectivity and Proceed in the lower part of the page. The following table describes the parameters.
Section
Parameter
Description
N/A
Task Name
The name of the task. DTS automatically assigns a name to the task. We recommend that you specify a descriptive name that makes it easy to identify the task. You do not need to specify a unique task name.
Source Database
Select a DMS database instance
If you registered a source database with DMS, you can select the database. After you select the source database, you do not need to enter information about the database. If you did not register a source database with DMS, ignore this option.
Database Type
The type of the source database. Select ApsaraDB for Redis Enhanced Edition (Tair).
Access Method
The access method of the source database. Select the access method based on the deployment location of the source database. If the source database is deployed in an on-premises data center or on a third-party cloud platform, select Public IP Address.
In this example, Self-managed Database on ECS is selected.
Instance Region
The region in which the ECS instance resides. If the ECS instance is deployed in an on-premises data center or on a third-party cloud platform, select the region of the nearest source database.
Replicate Data Across Alibaba Cloud Accounts
Specifies whether to migrate data across Alibaba Cloud accounts. In this example, No is selected.
ECS Instance ID
The ID of the ECS instance on which the source database is deployed.
NoteIf the source database uses the cluster architecture, select the ID of the ECS instance on which a master node is deployed.
Instance Mode
The architecture of the source database. Select Standalone or Cluster.
Port Number
The service port number of the source database. The default port number is 6379.
NoteIf the source database uses the cluster architecture, enter the service port number of a master node.
Database Password
The password used to connect to the source database.
NoteThis parameter is optional. You can leave the parameter empty.
If you use a custom account, make sure that the account has read permissions. Specify the database password in the <user>:<password> format. For example, if the username of the custom account that you use to log on to the source database is admin and the password is Rp829dlwa, the database password is admin:Rp829dlwa.
Destination Database
Select a DMS database instance
If you registered a destination database with DMS, you can select the database. After you select the destination database, you do not need to enter information about the database. If you did not register a destination database with DMS, ignore this option.
Database Type
The type of the destination database. By default, ApsaraDB for Redis Enhanced Edition (Tair) is selected.
Access Method
The access method of the destination database. Select Alibaba Cloud Instance.
Instance Region
The region in which the destination ApsaraDB for Redis instance resides.
Instance ID
The ID of the destination ApsaraDB for Redis instance.
Database Password
The password used to connect to the destination database on the ApsaraDB for Redis instance.
NoteIf you use a custom account, make sure that the account has write permissions. Specify the database password in the <user>:<password> format. For example, if the username of the custom account that you use to log on to the destination database is admin and the password is Rp829dlwa, the database password is admin:Rp829dlwa.
Configure task objects and click Next: Advanced Settings in the lower part of the page. The following table describes the parameters.
Parameter
Description
Migration Types
The data migration type. Select a data migration type based on your business requirements.
Full Data Migration and Incremental Data Migration (default): uses the native synchronization logic of Redis to write data to the destination database by means of memory snapshots. This way, data from the source database is migrated without downtime.
If you do not have the SYNC or PSYNC permission on the source database, select Full Data Migration.
Full Data Migration: runs the SCAN command to traverse the source database and writes the traversed data to the destination database. To ensure data consistency, do not write new data to the source database during migration.
Processing Mode of Conflicting Tables
Precheck and Report Errors (default): checks whether keys exist in the destination database.
If keys exist, an error is returned during the precheck and the data migration task cannot be started. If keys do not exist, the precheck is passed.
Ignore Errors and Proceed: skips the Check the existence of objects in the destination database check item. If a key with the same name already exists in the destination database, the key is overwritten.
Source Objects and Selected Objects
Select the objects that you want to migrate in the Source Objects section and click to move the objects to the Selected Objects section. To remove a selected object, select the object in the Selected Objects section and click to move the object to the Source Objects section.
NoteYou can select databases (DB 0 to DB 255) as the objects that you want to migrate.
Configure the advanced settings and click Next Step: Data Verification in the lower part of the page.
In most cases, you can retain the default settings. For more information, see the "Appendix: Advanced settings" section of this topic.
Configure data verification and click Next: Save Task Settings and Precheck in the lower part of the page.
In most cases, you can retain the default settings. For more information, see Configure data verification.
Perform a precheck, and click Next: Purchase Instance in the lower part of the page.
If Warning or Failed items are generated during the precheck, check the items individually. You can click View Details and troubleshoot the issues. You can also click Confirm Alert Details and ignore the check items. However, issues such as data inconsistency may occur, which may pose risks to your business. For more information, see FAQ. After you complete the preceding operations, perform another precheck.
On the buy page, configure the parameters and click Buy and Start.
(Optional) Select the resource group to which the DTS data migration instance belongs. The default value is default resource group.
(Optional) Select the specifications of the DTS data migration instance. Higher specifications result in faster migration speed and higher costs. The default value is large. For more information, see Specifications of data migration instances.
Read and select the terms of service.
After you purchase the DTS data migration instance, the data migration task starts. You can view the progress of the data migration task on the data migration page.
What to do next
If you perform incremental data migration, you must manually terminate or release the data migration task in the console after the migration is complete.
You can verify the data. For more information, see Verify migrated Redis data.
References
If you do not want to migrate your database online, you can use the lightweight tool redis-cli to import AOFs for data migration. For more information, see Use AOFs to migrate data.
FAQ
Why does the connectivity test fail?
Take note of the following factors when you perform troubleshooting:
The account password is invalid. The password must be in the
user:password
format. For more information, see Logon methods.If the source database is a self-managed database that is deployed in an on-premises data center or on a third-party cloud platform, a network firewall may block access from DTS servers. In this case, manually add the CIDR blocks of DTS servers in the corresponding region to allow access from the servers. For more information, see Add the CIDR blocks of DTS servers.
Why does the migration task fail to run?
If you scale or change the specifications or endpoint of the source or destination database when you run a data migration task, the task fails. In this case, reconfigure the data migration task to account for the changes.
If the destination instance does not have sufficient available memory or the destination instance is a cluster instance whose specific shard has reached the upper memory limit, the DTS data migration task fails due to an out of memory (OOM) error.
If transparent data encryption (TDE) is enabled for the destination instance, you cannot use DTS to migrate data.
Why are data volumes different in the source and destination databases?
If an expiration policy is enabled for specific keys in the source database, these keys may not be deleted at the earliest opportunity after they expire. In this case, the number of keys in the destination database may be smaller than the number of keys in the source database.
When you run the PSYNC or SYNC command to transmit list data, DTS does not perform the FLUSH operation on the existing data in the destination database. As a result, duplicate data may exist.
If the network is interrupted during a full data migration, DTS may perform multiple full data migrations after the connection is reestablished. In this case, DTS automatically overwrites existing keys that have the same name in the destination database. If you perform a delete operation on the source database at this time, the command is not synchronized to the destination database. As a result, the destination database may have more keys than the source database.
Why should I check whether the eviction policy is noeviction?
By default, the maxmemory-policy parameter that specifies how data is evicted is set to volatile-lru for ApsaraDB for Redis instances. If the destination database does not have sufficient memory, data inconsistency may occur between the source and destination databases due to data eviction. In this case, the data migration task does not stop running. To prevent data inconsistency, we recommend that you set the maxmemory-policy parameter to noeviction for the destination database. This way, the data migration task fails if the destination database does not have sufficient memory, but you can prevent data loss in the destination database. For more information about data eviction policies, see What is the default eviction policy of ApsaraDB for Redis?
Why does a key whose prefix is DTS_REDIS_TIMESTAMP_HEARTBEAT exist in the source database?
To ensure the efficiency of data migration and synchronization, DTS inserts a key whose prefix is DTS_REDIS_TIMESTAMP_HEARTBEAT into the source database to record the points in time when updates occur. If the source database uses the cluster architecture, DTS inserts the key into each shard. DTS filters out the key during data migration. After the data migration is complete, the key automatically expires.
Which commands are supported for incremental data migration?
The following commands are supported for incremental data migration:
APPEND
BITOP, BLPOP, BRPOP, and BRPOPLPUSH
DECR, DECRBY, and DEL
EVAL, EVALSHA, EXEC, EXPIRE, and EXPIREAT
FLUSHALL and FLUSHDB
GEOADD and GETSET
HDEL, HINCRBY, HINCRBYFLOAT, HMSET, HSET, and HSETNX
INCR, INCRBY, and INCRBYFLOAT
LINSERT, LPOP, LPUSH, LPUSHX, LREM, LSET, and LTRIM
MOVE, MSET, MSETNX, and MULTI
PERSIST, PEXPIRE, PEXPIREAT, PFADD, PFMERGE, PSETEX, and PUBLISH
RENAME, RENAMENX, RESTORE, RPOP, RPOPLPUSH, RPUSH, and RPUSHX
SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, and SUNIONSTORE
ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, and ZREMRANGEBYSCORE
XADD, XCLAIM, XDEL, XAUTOCLAIM, XGROUP CREATECONSUMER, and XTRIM
If you run the EVAL or EVALSHA command to call Lua scripts, DTS cannot identify whether these Lua scripts are executed in the destination database. This is because the destination database does not explicitly return the execution results of Lua scripts during incremental data migration.
Appendix: Advanced settings
Parameter | Description |
Retry Time for Failed Connections | The retry time range for failed connections. If the source or destination database fails to be connected after the data migration task is started, DTS continuously retries to establish a connection within the specified time range. Valid values: 10 to 1440. Unit: minutes. Default value: 720. If DTS is reconnected to the source and destination databases within the specified time range, DTS resumes the data migration task. Otherwise, the data migration task fails. We recommend that you configure the Retry Time for Failed Connections parameter based on your business requirements, or set the parameter to a value that is greater than 30. When DTS retries a connection, you are charged for the DTS instance. |
The wait time before a retry when other issues occur in the source and destination databases. | The retry time range for other issues. If non-connectivity issues occur on the source or destination database after the data migration task is started, DTS reports errors and continuously retries the operations within the retry time range. Valid values: 10 to 1440. Unit: minutes. Default value: 10. If the operations are completed within the specified retry time range, DTS resumes the data migration task. Otherwise, the data migration task fails. We recommend that you set the parameter to a value that is greater than 10. |
Enable Throttling for Incremental Data Migration | The load on the destination database may increase when DTS migrates incremental data to the destination database. You can configure throttling thresholds for the number of rows and the amount of data that can be incrementally migrated per second based on your business requirements to help reduce the load on the destination database. The default value is No. |
Environment Tag | The environment tag that is used to identify the DTS instance. You can select an environment tag based on your business requirements. |
Extend Expiration Time of Destination Database Key | The extended expiration time of keys in the destination database for which time-to-live (TTL) values are specified. Default value: 1800. Unit: seconds. During data migration, if an expired key exists in the source database, the key is not migrated to the destination database. |
Use Slave Node | If the Instance Mode parameter of the source database is set to Cluster, you can select whether to read data from the replica nodes. By default, No is selected, which specifies that DTS reads data from the master node. |
Configure ETL | Specifies whether to configure the extract, transform, and load (ETL) feature. For more information, see What is ETL? Valid values:
|
Monitoring and Alerting | Specifies whether to configure alerting for the data synchronization task. If the task fails or the synchronization latency exceeds the specified threshold, alert contacts will receive notifications. Valid values:
|