Limitations when migrating data from a Redis source

Type

Description

Source database limitations

• The source server must have sufficient outbound bandwidth. Insufficient bandwidth slows migration.

• Tair (Redis OSS-Compatible) version 2.8 is not supported as a source database.

• If you perform only full data migration (select only Full Data Migration for Migration Types), do not write new data to the source during migration. Otherwise, source and destination data becomes inconsistent. For real-time consistency, select both full and incremental data migration.

• In a migration scenario that involves only Full Data Migration, DTS runs the INFO Keyspace command on the source to identify databases (DBs) with data. Only DBs in the INFO Keyspace result are migrated.

  Important

  Some third-party Redis services may not correctly list all DBs in the INFO Keyspace output, causing those DBs to be skipped. Before configuring the migration, run INFO Keyspace on the source to verify all required DBs are listed.

• When migrating from standalone to cluster Redis, note that clusters allow a command to operate on only one slot. Multi-key operations across slots return the following error:

  CROSSSLOT Keys in request don't hash to the same slot

  To avoid task interruption, use only single-key operations.

• DTS inserts a key prefixed with DTS_REDIS_TIMESTAMP_HEARTBEAT into the source to track update timestamps (one per shard in cluster mode). This key is filtered during migration and expires after the task completes.

• If the source instance is read-only or the DTS account does not have write (SETEX) permissions, the reported latency may be inaccurate.

• To ensure a stable migration link, increase the repl-backlog-size parameter in redis.conf.

• 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 as described in Steps.

• If the source Redis instance uses extended modules such as RedisJSON, RediSearch, RedisBloom, RedisTimeSeries, RedisGraph, RedisAI, RedisGears, RedisCell, RediSQL, redis-tdigest, or RedisCompat, DTS cannot parse their RDB storage formats and the task fails.

• DTS migrates data only from the selected child instance in a Tair (Enterprise Edition) Global Distributed Cache. Data from other child instances is not migrated.

  Note

  If you need to migrate data from other child instances in the group, for assistance, join the DTS User Group on DingTalk (ID: 116655009709). The DingTalk client is available for download.

Other limitations

• Capacity-optimized Tair (Enterprise Edition) instances are not supported as a source or target database.

• Scaling (adding or removing shards), instance specification change (memory increase, spec change, or zone migration), or connection address and port changes during migration interrupt the task because DTS loses continuous log data. If this occurs, clear the data migrated to the target Redis instance before reconfiguring the task.

• If the source or target is a self-managed Redis instance (where the Access Method is not Alibaba Cloud Instance), a connection address change during migration (such as an instance migration or Access Method) may cause retries, high latency, task failure, or data inconsistency. Monitor the task closely and reconfigure if anomalies occur.

• Data loss may occur on the target after an instance migration (including primary/secondary switchover) if unreplicated data exists on the primary.

• If the target has insufficient memory and triggers data eviction, data inconsistency may occur. The default data eviction policy (maxmemory-policy) for Tair (Redis OSS-Compatible) is volatile-lru. The migration task is not affected.

  To prevent this, set the target eviction policy to noeviction. When memory is full, writes and the task fail, but no data is evicted from the target.

  Note

  Redis data eviction policies.

• For Lua scripts called by EVAL or EVALSHA, DTS cannot confirm whether the scripts were successfully executed during incremental data migration. This is because the target does not explicitly return an execution result.

• List data may be duplicated because DTS does not Flush existing destination data when using psync or sync.

• If some source keys have expiration policies, the target may have fewer keys because expired keys may not yet be deleted from the source.

  Note

  Non-expiring key counts remain consistent between source and target.

• Use consistent Redis versions for source and target. Older-to-newer version migration is supported.

  Note

  Newer-to-older version migration may cause compatibility issues.

• When the Access Method for a Redis instance is Public IP Address, the Instance Mode does not support Cluster.

• Full data migration increases load on both databases. Run the migration during off-peak hours.

• Full data migration uses concurrent INSERT operations, which can cause fragmentation. The target may use more storage space than the source.

• DTS auto-resumes failed tasks for up to seven days. Before switching to the target instance, end or release the task, or revoke DTS write permissions on the target using the revoke command. This prevents a resumed task from overwriting target data.

• If a cluster shard reaches its memory limit or the target runs out of storage, the task fails with an out of memory (OOM) error.

• DTS does not support data migration if Transparent Data Encryption (TDE) is enabled on the source or target instance.

• The following events during migration may cause full data migration to restart, leading to data inconsistency:

  • A transient connection interruption on the source or target Redis instance causes resumable transmission to fail.

  • A primary/secondary switchover or failover occurs on the source or target Redis instance.

  • The connection address of the source or target Redis instance changes.

• If a Tair (Redis OSS-Compatible) instance has Transport Layer Security (TLS) encryption enabled, you must connect to it by using the SSL-encrypted method in DTS. TLSv1.3 is not supported. You cannot connect to an SSL-enabled Tair (Redis OSS-Compatible) instance by setting the Alibaba Cloud Instance to Alibaba Cloud Instance.

• If a task includes both full and incremental migration, DTS may re-run both after the migration instance restarts.

• Restarting the migration instance may re-execute commands, causing data inconsistency—especially with non-idempotent commands like INCRBY or LPUSH, or if the restart triggers a new full data migration.

• 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 is a self-managed Redis database:

• A primary/secondary switchover on the source during migration causes the task to fail.

• DTS calculates migration latency by comparing the last migrated record's timestamp with the current time. If no DML operations occur on the source for an extended period, reported latency may be inaccurate. Perform a DML operation on the source to refresh the latency.

  Note

  For full database migrations, create a heartbeat table that updates every second.