Type | Description |
Source database limits | Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, data migration speed will be affected. The source database does not support Tair (Redis OSS-compatible) version 2.8. Source database operation limits: If you perform only full data migration (during task configuration, set Migration Types to Full Data Migration only), do not write new data to the source instance. Otherwise, data inconsistency between source and destination will occur. To maintain real-time data consistency, select both full and incremental data migration. Limits when migrating from a Basic Edition Redis source to a cluster architecture destination: Because Redis clusters allow only single-slot operations per command, multi-key operations that span multiple slots on the source will trigger the error: CROSSSLOT Keys in request don't hash to the same slot
To avoid link interruption during DTS migration, perform only single-key operations. To ensure migration quality, DTS inserts a key with the prefix DTS_REDIS_TIMESTAMP_HEARTBEAT into the source database to record update timestamps. If the source uses a cluster architecture, DTS inserts this key into every shard. This key is filtered out during migration and expires after the task ends. If the source database is a read-only instance or the DTS account lacks write (SETEX) permission, reported latency may be inaccurate. To ensure migration stability based on Redis replication backlog mechanisms, increase the repl-backlog-size parameter in the redis.conf configuration file. If the source instance is a Tair (Enterprise Edition) instance whose Storage Medium is Persistent Memory, 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) Global Distributed Cache, DTS supports migrating only the selected child instance due to inherent functional limitations. Migration of other child instances is not supported.
|
Other limits | Neither the source nor destination database supports Tair (Redis OSS-compatible) Enterprise Edition capacity storage instances. If scaling (adding or removing shards), instance specification changes (such as increasing memory, changing specifications or configurations, or zone migration), or endpoint and port modifications occur on the source or destination Redis during migration, DTS cannot obtain continuous log data or correct connection information. This will interrupt the migration task. If this occurs, clear all data already synchronized to the destination Redis before reconfiguring the task to ensure data consistency. When the source or destination is a self-managed Redis instance (Access Method is not Alibaba Cloud Instance), changes to the Redis endpoint during migration (for example, due to instance migration or master/standby switchover) may cause retries, delays, failures, or data inconsistency. Monitor the migration task status. If the DTS task shows abnormal behavior such as retries, delays, or failures, reconfigure the migration task. After a failover event (including master/standby switchover) on the destination Redis, data might be written only to memory without being replicated to the secondary database, causing data loss. If the destination database runs out of memory and triggers data eviction, the default data eviction policy (maxmemory-policy) for Tair (Redis OSS-compatible) is volatile-lru. This can cause data inconsistency between source and destination but will not affect normal task execution. To prevent this, set the destination database's eviction policy to noeviction. When memory is insufficient, write operations will fail and the task will stop, but no data will be evicted from the destination. For Lua scripts invoked via EVAL or EVALSHA, DTS cannot confirm successful execution during incremental migration because the destination does not explicitly return script execution results. For List data structures, DTS does not execute Flush on existing data at the destination when using psync or sync to transfer data. This may result in duplicate data. If some keys in the source database use expiration (expire) policies, expired keys might not be immediately deleted. Therefore, the number of keys visible in the destination (for example, via the info command) may be fewer than in the source.
Note The number of keys without expiration policies or unexpired keys is consistent between source and destination. Keep Redis versions consistent between source and destination to ensure compatibility. Migration from lower to higher versions is supported.
Note Migrating from a higher to a lower Redis version may introduce compatibility risks. When the Redis instance Access Method is Public IP Address, the Instance Mode does not support Cluster. Evaluate source and destination database performance before starting migration. Run data migration during off-peak business hours. During full data migration, DTS consumes read/write resources on both databases, which may increase database load. Because full data migration executes INSERT operations concurrently, table fragmentation occurs in the destination database. After full migration completes, the destination table storage space will be larger than the source. DTS attempts to recover failed migration tasks within seven days. Before switching your business to the destination instance, either stop or release the task, or revoke the DTS account's write permission to the destination instance using the revoke command. This prevents source data from overwriting destination data if the task auto-recovers. If the destination instance uses a cluster architecture and any shard reaches its memory limit, or if the destination instance runs out of storage space, the DTS task fails due to out-of-memory (OOM) errors. If transparent data encryption (TDE) is enabled on the source or destination instance, DTS does not support data migration. If any of the following events occur during migration, full data may be re-migrated to the destination, causing data inconsistency: Transient disconnections on the source or destination Redis cause breakpoint resume failure. Master/standby switchover or failover occurs on the source or destination Redis. The Redis endpoint changes on the source or destination.
If your Tair (Redis OSS-compatible) instance has TLS (Transport Layer Security) encryption enabled, you must connect to DTS using an SSL-encrypted (TLSv1.3 is not supported). Currently, you cannot use the Alibaba Cloud Instance method to connect to a Tair (Redis OSS-compatible) instance that has SSL enabled. If a migration instance includes both full and incremental tasks, restarting the instance may cause DTS to re-execute both tasks. Restarting a migration instance may cause some commands to execute repeatedly. This is especially true for non-idempotent commands (such as INCRBY or LPUSH) or when full migration restarts, potentially causing data inconsistency between source and destination. -
If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.
Note
Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.
|
Special cases | When the source database is self-managed Redis: Master/standby switchover on the source during migration causes task failure. DTS calculates latency by comparing the timestamp of the last migrated data record with the current timestamp. If the source database remains idle for DML operations over extended periods, latency reporting may become inaccurate. If the displayed latency appears excessive, execute a DML operation on the source to refresh latency information.
Note If migrating an entire database, create a heartbeat table that updates or writes data every second.
|