How to migrate a self-managed Redis database to a MyBase Redis instance-ApsaraDB for MyBase(MyBase)-阿里云帮助中心

This topic uses the new Data Transmission Service (DTS) console as an example. For instructions on how to migrate data from a self-managed MySQL database to MyBase MySQL using the old DTS console, see Migrate data from a self-managed Redis database to a Tair (Redis OSS-compatible) database.

Prerequisites

You have created a source self-managed Redis database and a destination Alibaba Cloud Redis instance. For more information about how to create an Alibaba Cloud Redis instance, see Create an instance.
The self-managed Redis database is version 2.8, 3.0, 3.2, 4.0, 5.0, or 6.0.
The self-managed Redis database can run the PSYNC or SYNC command.
The storage space of the MyBase Redis instance is larger than the storage space used by the self-managed Redis database.

Notes

DTS consumes resources on the source and destination databases during full data migration, which may increase the load on the database servers. If your database experiences high traffic or the server specifications are low, the increased load may cause the service to become unavailable. Before you migrate data, carefully evaluate the potential impact and perform the migration during off-peak hours.
If the destination database runs out of memory and triggers data eviction, data inconsistency may occur. This is because the default eviction policy (maxmemory-policy) for Tair (Redis OSS-compatible) is volatile-lru. The sync task continues to run, but the data becomes inconsistent.
To prevent this, you can set the eviction policy of the destination database to noeviction. If the destination database runs out of memory, data writes fail and the task fails. This prevents data loss due to eviction.
Note
For more information about data eviction policies, see Introduction to Redis data eviction policies.
If some keys in the source database are set to expire, they might not be deleted immediately upon expiration. As a result, the key count in the destination database, which you can check using the info command, might be lower than in the source database.
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.
For Lua scripts called by EVAL or EVALSHA, DTS cannot confirm if the scripts executed successfully during incremental data migration. This is because the destination database does not explicitly return the execution results.
When migrating List data, DTS uses psync or sync to transfer the data but does not perform a Flush operation on existing data in the destination database. This may result in data duplication.
If the self-managed Redis database is scaled (for example, by adding or removing shards) or its specifications are changed (for example, by increasing memory) during the migration, you must reconfigure the task. To ensure data consistency, clear all data in the destination database before you reconfigure the task.
If the endpoint of the self-managed Redis database changes during migration, you must reconfigure the task.
DTS automatically resumes failed tasks. To prevent an auto-resumed task from overwriting data in the destination instance, you must stop or release the task before you switch your services to the destination instance.
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.
If the destination instance is deployed in a cluster architecture and the amount of memory used by a shard in the destination instance reaches the upper limit, or if the available storage space of the destination instance is insufficient, the data synchronization task fails due to out of memory (OOM).
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.
If Transparent Data Encryption (TDE) is enabled for the destination instance, you cannot use DTS to migrate data.
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.
To migrate incremental data, the source account used for the task must have PSYNC and SYNC permissions.
If a Tair (Redis OSS-compatible) instance has the TLS (Transport Layer Security) encryption feature enabled, you must connect to DTS using an SSL-encrypted (TLSv1.3 is not supported). Connecting to a Tair (Redis OSS-compatible) instance with SSL enabled as a Alibaba Cloud Instance is not currently supported.
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.

Billing

Migration type	Link configuration fees	Data transfer cost
Schema migration and full data migration	Free of charge.	You are charged for data transfer when you migrate data out of Alibaba Cloud over the public network. For more information, see Billing overview.
Incremental data migration	Charged. For more information, see Billing overview.

Migration types

Full data migration
DTS migrates all historical data of the selected objects from the self-managed Redis database to the Tair (Redis OSS-compatible) instance.
Note
If you select only full data migration, do not perform DDL operations on the self-managed Redis database during the migration to ensure data consistency.
Incremental data migration
In addition to full data migration, DTS migrates incremental data updates from the self-managed Redis database to the Tair (Redis OSS-compatible) instance. Incremental data migration lets you migrate your Redis database to the cloud without service interruptions.

Commands supported for incremental data migration

APPEND
BITOP, BLPOP, BRPOP, BRPOPLPUSH
DECR, DECRBY, DEL
EVAL, EVALSHA, EXEC, EXPIRE, EXPIREAT
FLUSHALL, FLUSHDB
GEOADD, GETSET
HDEL, HINCRBY, HINCRBYFLOAT, HMSET, HSET, HSETNX
INCR, INCRBY, INCRBYFLOAT
LINSERT, LPOP, LPUSH, LPUSHX, LREM, LSET, LTRIM
MOVE, MSET, MSETNX, MULTI
PERSIST, PEXPIRE, PEXPIREAT, PFADD, PFMERGE, PSETEX, PUBLISH
RENAME, RENAMENX, RESTORE, RPOP, RPOPLPUSH, RPUSH, RPUSHX
SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, SUNIONSTORE
ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, ZREMRANGEBYSCORE
XADD, XCLAIM, XDEL, XAUTOCLAIM, XGROUP CREATECONSUMER, XTRIM

Preparations for incremental data migration

To ensure that the incremental data migration task runs as expected, remove the limit on the replication output buffer. This topic uses a server that runs Linux as an example.

Note

If you are performing only a full data migration, you can skip this step.

Use the redis-cli tool to connect to the self-managed Redis database.
Note
The redis-cli tool is available after you install Redis. For more information, see the official Redis community website.
```
redis-cli -h <host> -p <port> -a <password>
```
Note
- <host>: The endpoint of the self-managed Redis database. You can use 127.0.0.1.
- <port>: The service port of the self-managed Redis database. The default port is 6379.
- <password>: The password of the self-managed Redis database.
Example:
```
redis-cli -h 127.0.0.1 -p 6379 -a Test123456
```
Run the following command to remove the limit on the replication output buffer:
```
config set client-output-buffer-limit 'slave 0 0 0'
```

Create a migration task

Step 1: Open the migration task page

Use one of the following methods to reach the migration task list for the destination region.

From the DTS console

Log on to the DTS console.
In the left navigation pane, click Data Migration.
In the upper-left corner, select the region where the migration instance will be located.

From the DMS console

Note

The actual operations may vary based on the mode and layout of the DMS console. For more information, see Simple mode console and Customize the layout and style of the DMS console.

Log on to the DMS console.
In the top menu bar, choose Data + AI > Data Transmission (DTS) > Data Migration.
To the right of Data Migration Tasks, select the region.

Step 2: Configure source and destination databases

Click Create Task.

Configure the source database:

Field	Value
Task Name	DTS generates a name automatically. Specify a descriptive name for easy identification — it does not need to be unique.
Database Type	PolarDB for PostgreSQL
Connection Type	Cloud Instance
Instance Region	Region where the source PolarDB for PostgreSQL cluster resides
Across Alibaba Cloud Accounts	Not Cross-Account (for same-account migrations)
Instance ID	ID of the source PolarDB for PostgreSQL cluster
Database Name	Name of the source PolarDB for PostgreSQL database
Database Account	Account for the source database
Database Password	Password for the account

Configure the destination database:

Field	Value
Database Type	PostgreSQL
Connection Type	Cloud Instance
Instance Region	Region where the destination RDS for PostgreSQL instance resides
Instance ID	ID of the destination RDS for PostgreSQL instance
Database Name	Name of the database in the destination instance that will receive the migrated objects
Database Account	Account for the destination database
Database Password	Password for the account
Encryption	Select Non-encrypted or SSL-encrypted. For SSL encryption, upload the CA Certificate and, if using client certificates, the Client Certificate, Private Key of Client Certificate, and Private Key Password of Client Certificate.

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

Add the DTS server CIDR blocks to the security settings (IP whitelist) of both the source and destination databases before testing. See Add the IP address whitelist of DTS servers. If either database's Access Method is not Alibaba Cloud Instance, also click Test Connectivity in the CIDR Blocks of DTS Servers dialog box.

Step 3: Select migration objects

On the Configure Objects page:

Select the migration types:

If you skip Schema Migration, the destination database must already have the target schema and tables. If you skip Incremental Data Migration, do not write new data to the source instance during migration.

Goal	Migration types to select
Full migration only (with maintenance window)	Schema Migration + Full Data Migration
Near-zero-downtime migration	Schema Migration + Full Data Migration + Incremental Data Migration

Set Processing Mode of Conflicting Tables:
- Precheck and Report Errors: DTS checks for tables with the same name in the destination before starting. If a conflict exists, the task does not start. To resolve naming conflicts without deleting data, use Object name mapping.
- Ignore Errors and Proceed: Skips the conflict check. During full migration, conflicting records in the destination are kept. During incremental migration, source records overwrite destination records. Use with caution — inconsistent schemas may cause partial or failed migration.
(Optional) Configure Case Policy for Destination Object Names to control case sensitivity for migrated object names. The default is DTS default policy. See Case sensitivity of object names in the destination database.
In the Source Objects box, click the schemas or tables to migrate, then click the right-arrow icon to move them to the Selected Objects box.

- Selecting tables as migration objects excludes views, triggers, and stored procedures. - If a table contains a SERIAL field and Schema Migration is selected, also include Sequence or migrate the entire schema.
(Optional) To rename objects in the destination:
- Single object: right-click it in Selected Objects. See Map a single table or column name.
- Multiple objects: click Batch Edit in the upper-right corner of the Selected Objects box. See Map multiple table or column names in a batch.
Object name mapping may cause dependent objects to fail migration.

Step 4: Configure advanced settings

Click Next: Advanced Settings and configure the following options:

Setting	Description
Dedicated Cluster for Task Scheduling	DTS uses a shared cluster by default. Purchase a dedicated cluster for more stable task scheduling.
Retry Time for Failed Connections	Duration DTS retries after a connection failure. Default: 720 minutes. Range: 10–1440 minutes. Set to at least 30 minutes. The task resumes automatically if reconnected within the retry window; otherwise it fails.
Retry Time for Other Issues	Duration DTS retries after non-connectivity errors (DDL or DML exceptions). Default: 10 minutes. Range: 1–1440 minutes. Must be less than Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Limit QPS to the source, RPS of the migration, or migration speed (MB/s) to reduce database load during full migration. Adjustable after the instance starts.
Enable Throttling for Incremental Data Migration	Limit RPS or migration speed (MB/s) for incremental migration. Adjustable after the instance starts.
Configure ETL	Enable extract, transform, and load (ETL) to apply data transformations during migration. See Configure ETL in a data migration or data synchronization task.
Monitoring and Alerting	Configure alert thresholds and notifications. DTS sends alerts when a migration fails or latency exceeds the threshold.
Environment Tag	Tag the instance for environment identification (optional).

Step 5: Configure data validation (optional)

Click Next: Data Validation to set up a data validation task. See Configure data validation.

Step 6: Save the task and run a precheck

Click Next: Save Task Settings and Precheck at the bottom of the page.

To view API parameters for this configuration, hover over the Next: Save Task Settings and Precheck button and click Preview OpenAPI parameters.

DTS runs a precheck before the migration starts. If the precheck fails:

For failed items: click View Details, fix the issue, then click Precheck Again.
For warning items that can be ignored: click Confirm Alert Details > Ignore > OK > Precheck Again. Ignored warnings may cause data inconsistency.

Step 7: Purchase and start the instance

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

On the Purchase page, select the instance class:

Field	Description
Resource Group Settings	Resource group for the instance. Default: default resource group. See What is Resource Management?
Instance Class	Controls migration speed. See Data migration link specifications.

Read and accept Data Transmission Service (Pay-as-you-go) Service Terms.
Click Buy and Start, then click OK in the confirmation dialog box.

The migration task appears on the Data Migration Tasks list page. If the task includes only schema and full migration, it stops automatically when complete and the Status changes to Completed. If the task includes incremental migration, it continues running with Status showing Running.

Step 8: Switch over to the destination database

Before switching your applications to the destination instance:

Wait until all pending changes from the source database have been applied to the destination. If incremental migration is running, monitor the task latency until it reaches zero.
Update sequence values in the destination database. Sequences do not automatically start from the maximum value in the source database after a switchover. See Update the sequence value of the destination database.
End or release the DTS migration task, or revoke the write permissions of the DTS account using the revoke command. This prevents DTS from overwriting destination data if the task is automatically recovered.

If you manually set session_replication_role to replica in the destination database before migration, reset it to origin now.
Reconnect your applications to the destination RDS for PostgreSQL instance.

What to do next

The database account used for data migration has read and write permissions. To ensure database security, we recommend that you change the passwords for your self-managed Redis database and the MyBase Redis instance after the data migration is complete.