Data Transmission Service:Migrate data between Tair (Redis OSS-Compatible) instances across Alibaba Cloud accounts

Source instance

• The source instance version cannot be 2.8.

• The source server must have enough outbound bandwidth. Insufficient bandwidth reduces migration speed.

• During full data migration only: do not write to the source instance. Writes during full-only migration cause data inconsistency. To avoid this, select both full and incremental migration types.

• A storage-optimized Tair (Redis OSS-Compatible) Enhanced Edition instance cannot be the source or destination.

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

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

Destination instance

• The destination Redis version must be the same as or later than the source version. An older destination version causes compatibility issues.

• The default data eviction policy (maxmemory-policy) is volatile-lru. If memory runs out, data inconsistency may occur. We recommend that you set the policy to noeviction so that DTS fails writes explicitly rather than silently evicting data.

• If Transparent Data Encryption (TDE) is enabled on the destination, DTS cannot migrate data.

• If a shard in the destination cluster runs out of memory, or available storage is insufficient, the migration task fails with an out of memory (OOM) error.

Other limitations

• When DTS transfers LIST type data using PSYNC or SYNC, it does not flush existing data in the destination. Duplicate records may result.

• DTS cannot confirm whether Lua scripts (run via EVAL or EVALSHA) execute successfully on the destination during incremental migration, because the destination does not return explicit execution results.

• Keys with an expiration policy may not be deleted immediately after expiry. The number of keys in the destination may be temporarily fewer than in the source. Run the INFO command to check the key count.

• After full data migration, the destination tablespace is larger than the source due to fragmentation from concurrent INSERT operations.

• DTS retries failed migration tasks for up to seven days. Before switching traffic to the destination, stop or release any failed tasks — otherwise, DTS may overwrite destination data with source data when the task resumes.

• If source or destination database configurations change (such as specifications or port number) during migration, the task is interrupted. Delete destination data and reconfigure the migration task after the change.

• During full data migration, DTS consumes read and write resources on both instances and increases server load. Run migrations during off-peak hours.

• If resumable upload fails during data migration due to transient connections that occur on the source Redis database, full data may be migrated to the destination database again. This may cause data inconsistency between the source and destination databases.

Cluster architecture limitations

• Each Redis command in a cluster can only operate on keys within a single slot. If a command targets keys across multiple slots, the following error occurs:

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

  Operate on one key at a time during migration to avoid this error.

• When migrating from a standalone source to a cluster destination, commands that span multiple slots cause the migration task to stop.

Self-managed Redis special cases

If the source database is a self-managed Redis database, take note of the following additional limitations:

• If you perform a primary/secondary switchover on the source database while the data migration task is running, the migration task fails.

• DTS calculates migration latency based on the timestamp of the latest migrated data in the destination database and the current timestamp in the source database. If no DML operation is performed on the source database for an extended period of time, the migration latency may be inaccurate. Perform a DML operation on the source database to refresh the latency. If you selected an entire database as the migration object, you can create a heartbeat table that receives writes every second.

Step 1: Open the Data Migration Tasks page

Go to the Data Migration Tasks page using either console:

DTS console

1. Log on to the DTS console.

2. In the left-side navigation pane, click Data Migration.

3. In the upper-left corner, select the region where the migration instance resides.

DMS console

The exact navigation path may vary depending on your DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console.

1. Log on to the DMS console.

2. In the top navigation bar, move the pointer over Data + AI > DTS (DTS) > Data Migration.

3. From the drop-down list to the right of Data Migration Tasks, select the region where the migration instance resides.

Step 2: Create a task

1. Click Create Task.

2. (Optional) If New Configuration Page appears in the upper-right corner, click it. Skip this step if Back to Previous Version is shown instead.

Specific parameters may differ between the new and previous configuration pages. Use the new version.

Step 3: Configure the source and destination databases

Configure the following parameters:

Source database

Destination database

Step 4: Test connectivity

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

DTS server CIDR blocks must be added to the security settings of both instances before the connectivity test succeeds. See Add the CIDR blocks of DTS servers. For self-managed databases not using Alibaba Cloud Instance access, click Test Connectivity in the CIDR Blocks of DTS Servers dialog box.

Step 5: Configure objects to migrate

On the Configure Objects page, set the following parameters:

Click Next: Advanced Settings.

Step 6: Configure advanced settings

Click Next Step: Data Verification to configure data verification. See Configure a data verification task.

Step 7: Save and run the precheck

• To preview API parameters for this task, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.

• Click Next: Save Task Settings and Precheck to save the configuration and start the precheck.

The migration task cannot start until the precheck passes.

If a check item fails, click View Details next to it, fix the issue, then click Precheck Again.

If a check item raises an alert that you can safely ignore, click Confirm Alert Details > Ignore > OK, then click Precheck Again. Ignoring alerts may cause data inconsistency.

Step 8: Purchase an instance and start the task

1. Wait until Success Rate reaches 100%, then click Next: Purchase Instance.

2. On the Purchase Instance page, configure the following:

   Parameter	Description
   Resource Group	The resource group for the migration instance. Default: default resource group. See What is Resource Management?.
   Instance Class	Select an instance class based on your required migration speed. See Instance classes of data migration instances.

3. Read and agree to Data Transmission Service (Pay-as-you-go) Service Terms by selecting the checkbox.

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

Monitor task progress on the Data Migration page.

If the task uses both full and incremental migration types, Incremental Data Migration is displayed as the active phase after full migration completes.