Redis
UDTS can use native Redis or distributed versions with proxies (including Surfercloud Redis distributed version, Codis, Twemproxy) as data sources/targets to perform full and incremental data transfer tasks. The currently supported versions range from 3.0 to 6.0, as well as 7.0 for master-slave versions. Cross-major version migrations may have compatibility issues; it is recommended to migrate via an intermediate library. For example, when migrating from 3.x/4.x to 7.x, you need to create an intermediate library with version 5.x/6.x, first migrating from 3.x/4.x to 5.x/6.x, and then from 5.x/6.x to 7.x.
Functional Limitations
- If the source is a read-write separated version, rump mode migration is required, which only supports full migration, not incremental. Version 7.0 does not support rump mode.
Notes
- The number of nodes in the source and target clusters does not need to match.
- Ensure the
repl-diskless-syncconfiguration of the source database is set toNO. - If the source is a distributed version (including Surfercloud Redis distributed version, Codis, Twemproxy), multiple tasks need to be created, entering one distributed node address as the source database for each task, and selecting the master-slave type.
- When the target is Surfercloud Redis distributed version, choose the distributed type for the target and use the proxy address.
- When the target is Surfercloud Redis Distributed Cluster version and provides a proxy address, choose the distributed type for the target and use the proxy address.
- When the target is Surfercloud Redis Distributed Cluster version without a proxy address, choose the cluster type for the target and use the shard address, with multiple addresses separated by ”;”.
- When the target is a cluster version, only db0 migration is supported.
- UDTS will not automatically clean data in the target database. Data with the same Key in the source database will overwrite the target, while data with different Keys will be retained.
- Redis does not automatically delete expired keys when they expire. Generally, it uses lazy deletion (checking expiration upon access and deleting if expired) and periodic deletion (iteratively deleting a certain number of keys periodically). Thus, there may be some expired keys in the source, which will not be synchronized to the target.
Redis Form Filling
| Parameter Name | Description |
|---|---|
| Address | Database address, only enter the master address. In cluster mode, multiple addresses are connected with ”;”, e.g., 192.168.1.100:6379;192.168.1.120:6379;192.168.1.130:26379 |
| Password | Redis password, optional |
| Redis Type | Cluster Mode/Master-Slave Mode/Distributed Version |
| VPC ID | VPC ID, VPC to which Redis belongs |
| Subnet | Subnet under the VPC, subnet to which Redis belongs |
| Enable Rump Sync | Rump synchronization is needed when users lack psync permission. |
Resumable Transmission
Resumable transmission will be automatically enabled under the following conditions:
- The task has reached the incremental stage.
- The source and target types are identical, such as master-slave mode transmitted to master-slave mode, and cluster mode to cluster mode.
- When both source and target are in cluster mode, the number of nodes in the source and target clusters is the same.
- The version of the source database is from 3.0 to 6.0.