Type | Description |
Source database limits | Bandwidth requirements: The server that hosts the source database must have sufficient outbound bandwidth. Otherwise, the data migration speed is affected. The source database cannot be Tair (Redis OSS-compatible) version 2.8. Source database operation limits: If you perform only a full data migration (only Migration Types is set to Full Data Migration), do not write new data to the source instance. Otherwise, data inconsistency between the source and destination instances occurs. To maintain real-time data consistency, select both full data migration and incremental data migration. Operation limits for migrating from a Basic Edition Redis instance to a cluster architecture Redis instance: A Redis cluster allows a single command to operate on only a single slot. If you run a multi-key operation on the source database and the keys are not in the same slot or involve multiple slots, the following error is reported: CROSSSLOT Keys in request don't hash to the same slot
During DTS migration, run only single-key operations to prevent link interruptions. To ensure migration quality, DTS inserts a key with the prefix DTS_REDIS_TIMESTAMP_HEARTBEAT into the source database to record the update timestamp. If the source database uses a cluster architecture, DTS inserts this key into each shard. This key is filtered out during migration and expires after the migration task is complete. If the source database is a read-only instance or the DTS account does not have write (SETEX) permissions, the reported latency may be inaccurate. If the source instance is a Tair (Enterprise Edition) instance that uses Persistent Memory as the Storage Medium, ensure that the appendonly parameter is set to yes. For more information, see Procedure. If the source is a child instance of a Tair (Enterprise Edition) instance that uses the Global Distributed Cache feature, DTS can migrate data from only the selected child instance due to the limits of the instance. DTS cannot migrate data from other child instances.
|
Other limits | The source and destination databases cannot be Tair (Redis OSS-compatible) Enterprise Edition instances that use the capacity storage type. During migration, if the source or destination Redis instance is scaled out or in (for example, by adding or removing shards), upgraded or downgraded (for example, by increasing memory, changing specifications or configurations, or migrating zones), or its endpoint and port number are changed, DTS may fail to obtain continuous log data and correct connection information. This interrupts the migration task. If this occurs, clear the data that has been synchronized to the destination Redis instance before you reconfigure the task. If the source or destination instance is a self-managed Redis instance (the Access Method is not Alibaba Cloud Instance), and its endpoint changes during migration (for example, due to an instance migration or a primary/secondary switchover), the migration task may experience retries, delays, failures, or even data inconsistency. Check the status of the migration task promptly. If the DTS task is abnormal, such as retrying, delayed, or failed, reconfigure the migration task. After an instance migration (including a primary/secondary switchover) is triggered on the destination Redis instance, data may be written only to memory and not to the secondary database. This can cause data loss. If the destination database is out of memory and data eviction is triggered, data inconsistency between the source and destination databases may occur. This is because the default data eviction policy (maxmemory-policy) for Tair (Redis OSS-compatible) is volatile-lru. However, this does not affect the normal operation of the task. To prevent this, set the data eviction policy of the destination database to noeviction. When the destination database is out of memory, data writes will fail, and the task will also fail, but no data will be lost due to eviction. For Lua scripts called using EVAL or EVALSHA, DTS cannot confirm whether the scripts are successfully executed during incremental data migration. This is because the destination does not explicitly return the execution result. For List objects, duplicate data may appear. This is because DTS does not perform a Flush operation on existing data at the destination when it uses psync or sync to transfer data. If some keys in the source database use an expiration (expire) policy, the number of keys in the destination database (for example, viewed using the info command) may be less than that in the source database. This is because expired keys may not be deleted promptly.
Note The number of keys that do not have an expiration policy or have not expired is the same in the source and destination databases. Use the same Redis version for the source and destination databases to ensure compatibility. Migration from an earlier version to a later version is supported.
Note If you migrate data from a later version to an earlier version, compatibility issues may occur. If the Access Method for the Redis instance is Public IP Address, the Instance Mode cannot be Cluster. Before you perform data migration, evaluate the performance of the source and destination databases. Also, perform data migration during off-peak hours. Otherwise, DTS occupies some read and write resources of the source and destination databases during full data migration, which may increase the database load. Full data migration involves concurrent INSERT operations, which causes fragmentation in the tables of the destination database. Therefore, after the full migration is complete, the storage space used by the tables in the destination database is larger than that in the source instance. DTS attempts to recover failed migration tasks within seven days. Therefore, before you switch your business to the destination instance, make sure to end or release the task, or use the revoke command to revoke the write permissions of the account that DTS uses to access the destination instance. This prevents the source data from overwriting the data in the destination instance after the task is automatically recovered. If the destination instance uses a cluster architecture and a shard reaches its memory limit, or if the destination instance has insufficient storage space, the DTS task fails due to an Out of Memory (OOM) error. If Transparent Data Encryption (TDE) is enabled for the source or destination instance, you cannot use DTS to migrate data. If any of the following situations occur during data migration, the full data may be re-migrated to the destination, which can cause data inconsistency. A transient disconnection occurs on the source or destination Redis instance, causing the resumable transfer to fail. A primary/secondary switchover or failover occurs on the source or destination Redis instance. The endpoint of the source or destination Redis instance changes.
If a Tair (Redis OSS-compatible) instance has Transport Layer Security (TLS) encryption enabled, you must connect to DTS using an SSL-encrypted connection. TLSv1.3 is not supported. You cannot connect a Tair (Redis OSS-compatible) instance that has SSL enabled to DTS as a Alibaba Cloud Instance. If a migration instance includes both full and incremental tasks, restarting the instance may cause DTS to re-execute both tasks. If an instance fails, DTS helpdesk will try to recover the instance within 8 hours. During the recovery process, operations such as restarting the instance and adjusting parameters may be performed.
Note When parameters are adjusted, only the parameters of the DTS instance are modified. The parameters of the database are not modified. The parameters that may be modified include but are not limited to those described in Modify instance parameters.
|
Special cases | When the source database is a self-managed Redis instance: A primary/secondary switchover on the source database during migration causes the migration task to fail. The latency reported by DTS is calculated by comparing the timestamp of the last piece of data migrated to the destination database with the current timestamp. If no DML operations are performed on the source database for a long time, the latency information may be inaccurate. If the task displays a high latency, you can run a DML operation on the source database to update the latency information.
Note If you choose to migrate the entire database, you can also create a heartbeat table. The heartbeat table periodically updates or writes data every second.
|