Data Transmission Service:Cross-account migration

Source database limits

• Bandwidth requirement: The server hosting the source database must have sufficient outbound bandwidth. Otherwise, data migration speed will be affected.

• Version 2.8 of Tair (Redis OSS-compatible) is not supported as a source.

• If running full migration only (without incremental), stop writing to the source during migration to prevent data inconsistency.

• When migrating from a Basic Edition source to a cluster-architecture destination, use only single-key operations. Multi-key commands that span slots return:

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

• DTS inserts a key with the prefix DTS_REDIS_TIMESTAMP_HEARTBEAT into the source to track update timestamps. If the source uses a cluster architecture, this key is inserted into every shard. The key is filtered during migration and expires after the task ends.

• If the source is a read-only instance or the DTS account lacks SETEX permission, reported latency may be inaccurate.

• To improve migration stability, increase the repl-backlog-size parameter in redis.conf.

• If the source is a Tair Enterprise Edition instance with Storage Medium set to Persistent Memory, set the appendonly parameter to yes. For details, see Procedure.

• If the source is a child instance of a Global Distributed Cache, DTS migrates only that child instance. Other child instances are not supported.

Other limits

• Neither source nor destination supports Tair (Redis OSS-compatible) Enterprise Edition capacity storage instances.

• If transparent data encryption (TDE) is enabled on either instance, DTS cannot perform the migration.

• If the destination runs out of memory, the default eviction policy (maxmemory-policy) is volatile-lru, which can cause data inconsistency. To prevent silent data loss, set the destination eviction policy to noeviction. With noeviction, write operations fail when memory is full and the task stops, but no data is silently removed. For policy details, see Introduction to Redis data eviction policies.

• If the destination instance uses a cluster architecture and any shard reaches its memory limit, or if the instance runs out of storage space, the DTS task fails with an out-of-memory (OOM) error.

• Scaling operations (adding or removing shards), specification changes, or endpoint or port modifications on either instance during migration will interrupt the task. If this happens, clear all synchronized data from the destination and reconfigure the task.

• After a failover event (including master/standby switchover) on the destination, data may be written only to memory without replication to the secondary, causing data loss.

• 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 non-idempotent commands (such as INCRBY or LPUSH) to execute repeatedly, leading to data inconsistency.

• For Lua scripts invoked via EVAL or EVALSHA, DTS cannot confirm successful execution during incremental migration.

• For List data structures, DTS does not flush existing destination data when using psync or sync, which may result in duplicate entries.

• If keys in the source have expiration policies, the key count visible in the destination (for example, via INFO) may be lower than the source. Keys without expiration policies or unexpired keys are consistent between source and destination.

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

• Run migration during off-peak hours. Full migration consumes read and write resources on both instances.

• After full migration, destination storage space will be larger than the source due to concurrent INSERT operations.

• DTS attempts to auto-recover failed tasks for up to seven days. Before switching traffic to the destination, stop or release the task, or revoke the DTS account's write permission using REVOKE to prevent recovered tasks from overwriting destination data.

• If a TLS-encrypted Tair (Redis OSS-compatible) instance is involved, connect to DTS using SSL-encrypted (TLSv1.3 is not supported). Connecting with SSL-encrypted to an Alibaba Cloud Instance source is not currently supported.

• If a task fails, DTS support staff will attempt to restore it within eight hours. Restoration may involve restarting the task or adjusting task parameters. Only DTS task parameters are modified—not database parameters. For adjustable parameters, see Modify instance parameters.

Special cases for self-managed Redis sources

When the source Access Method is not Alibaba Cloud Instance:

• Master/standby switchover on the source causes task failure.

• DTS calculates latency by comparing the last migrated record's timestamp with the current time. If the source has no DML activity for an extended period, the displayed latency may be inaccurate. Run a DML operation on the source to refresh latency. If migrating an entire database, use a heartbeat table that writes data every second.

• 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 task status and reconfigure if abnormal behavior appears.

Step 1: Open the migration task list

Log on using the destination account and navigate to the data migration task list using one of these methods:

Step 2: Create the task

Click Create Task to open the task configuration page.

Step 3: Configure source and destination databases

Configure parameters for both the source and destination databases:

Task name

Source database

Destination database

Step 4: Test connectivity

Click Test Connectivity and Proceed at the bottom of the page.

Make sure the DTS service IP ranges are added to the security settings of both instances. See Add DTS server IP addresses to a whitelist.

If either instance is self-managed (Access Method is not Alibaba Cloud Instance), click Test Connectivity in the CIDR Blocks of DTS Servers dialog.

Step 5: Configure migration objects

On the Configure Objects page, set the following parameters:

Parameter	Description
Migration Types	Select both Full Data Migration and Incremental Data Migration for zero-downtime migration. Select Full Data Migration only if the DTS account lacks SYNC/PSYNC permission on the source.
Processing Mode of Conflicting Tables	Precheck and Report Errors: The precheck verifies that the destination is empty. If not, the task does not start. Ignore Errors and Proceed: Skips the empty-destination check. If a key in the destination has the same name as a source key, the source data overwrites the destination. This may cause data loss—proceed with caution.
Source Objects	Click objects in the Source Objects box, then click to move them to Selected Objects. Select whole databases or use data filtering for specific keys.
Selected Objects	To map databases (DB 0–255) or filter by key prefix, right-click a database in Selected Objects and configure in the Edit Schema dialog. See Schema mapping and Set filter conditions.

Click Next Advanced Settings and configure the following:

Click Next Data Verification to configure data verification. For details, see Configure a data verification task.

Step 6: Run the precheck

Click Next: Save Task Settings and Precheck.

To preview the API parameters for this configuration, hover over the button and click Preview OpenAPI parameters.

DTS runs a precheck before starting migration. The task starts only after the precheck passes.

If the precheck fails, click View Details next to the failed item, fix the issue, and run the precheck again.

If a warning appears: for items that cannot be skipped, fix the issue and rerun. For items that can be skipped, click Confirm Alert Details > Ignore > OK > Precheck Again. Ignoring warnings may cause data inconsistency.

Step 7: Purchase and start

1. When Success Rate reaches 100%, click Next: Purchase Instance.

2. On the Purchase page, select the instance class:

   Parameter	Description
   Resource Group Settings	Select the resource group for this instance. Default: default resource group. See What is Resource Management?.
   Instance Class	Select a specification based on your migration volume and speed requirements. See Data migration link specifications.

3. Read and accept Data Transmission Service (Pay-as-you-go) Service Terms.

4. Click Buy and Start, then click OK in the confirmation dialog.

Monitor migration progress on the data migration page.

If the task includes both full and incremental migration, it is displayed as Incremental Data Migration on the migration task list page.