This topic describes how to configure two-way data synchronization between ApsaraDB for Redis Enhanced Edition (Tair) instances by using Data Transmission Service (DTS). This feature is applicable to scenarios such as active geo-redundancy and geo-disaster recovery.
Prerequisites
The source and destination instances are ApsaraDB for Redis Enhanced Edition (Tair)
instances that run Redis 5.0. For more information about ApsaraDB for Redis Enhanced
Edition (Tair) instances, see Overview.
Note
- The source and destination instances cannot be storage-optimized instances.
- The source and destination instances use local disks rather than cloud disks.
- ApsaraDB for Redis Enhanced Edition (Tair) supports the cluster, standard, and read/write splitting architectures.
Precautions
- During two-way data synchronization, the data synchronization task in the forward
direction performs full data synchronization and incremental data synchronization. The data synchronization task in the reverse direction performs only incremental
data synchronization.
Warning To ensure data consistency, do not modify or write data to the same key in the source and destination databases when the two-way data synchronization tasks are running.
- DTS uses the resources of the source and destination databases during full data synchronization. This may increase the loads of the database servers. If you migrate a large volume of data or if the server specifications do not meet your requirements, database services may become unavailable. Before you synchronize data, evaluate the impacts of data synchronization on the performance of the source and destination instances. We recommend that you synchronize data during off-peak hours.
- We recommend that you do not run the
FLUSHDB
orFLUSHALL
command in the source instance during data synchronization. Otherwise, data may become inconsistent between the source and destination instances. - If the data eviction policy (
maxmemory-policy
) of the destination instance is not set tonoeviction
, data may become inconsistent between the source and destination instances. For more information about data eviction policies, see How does ApsaraDB for Redis evict data by default? - If an expiration policy is enabled for some keys in the source database, these keys
may not be deleted in a timely manner after they expired. Therefore, the number of
keys in the destination database may be less than that in the source database. You
can run the info command to view the number of keys in the destination 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.
- If direct connection is disabled for the destination ApsaraDB for Redis instance,
DTS uses the proxy forwarding mode to write data to the destination instance.
Note For more information about how to enable direct connection, see Enable the direct connection mode.
- During data synchronization, if the number of shards in the source or destination ApsaraDB for Redis instance is increased or decreased, or if the database specifications are changed (for example, the memory capacity is scaled up), you must reconfigure the task. To ensure data consistency, we recommend that you clear the data that has been synchronized to the source and destination Redis databases before you reconfigure the task.
- During data synchronization, if the endpoint of the source or destination ApsaraDB for Redis instance is changed, you must submit a ticket to update the endpoint. Operations that may cause endpoint changes include instance zone changes and network changes from the classic network to Virtual Private Cloud (VPC). Otherwise, the append-only files (AOF) of the source or destination ApsaraDB for Redis instance may be reset. In this case, you must reconfigure the task.
- If the source or the destination instance is located in a region outside the Chinese mainland, two-way data synchronization is supported only between instances located with the same region. For example, two-way data synchronization is supported between instances within the Japan (Tokyo) region. Two-way data synchronization between an instance in the Japan (Tokyo) region and another instance in the Germany (Frankfurt) region is not supported.
Commands that can be synchronized
- APPEND
- BITOP, BLPOP, BRPOP, and BRPOPLPUSH
- DECR, DECRBY, and DEL
- EVAL, EVALSHA, EXEC, EXPIRE, and EXPIREAT
- GEOADD and GETSET
- HDEL, HINCRBY, HINCRBYFLOAT, HMSET, HSET, and HSETNX
- INCR, INCRBY, and INCRBYFLOAT
- LINSERT, LPOP, LPUSH, LPUSHX, LREM, LSET, and LTRIM
- MOVE, MSET, MSETNX, and MULTI
- PERSIST, PEXPIRE, PEXPIREAT, PFADD, PFMERGE, and PSETEX
- RENAME, RENAMENX, RPOP, RPOPLPUSH, RPUSH, and RPUSHX
- SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, and SUNIONSTORE
- UNLINK, ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, and ZREMRANGEBYSCORE
- SWAPDB (This operation is not supported if the source or destination ApsaraDB for Redis instance is deployed in the cluster architecture.)
Notice
- PUBLISH commands cannot be synchronized.
- If you run the EVAL or EVALSHA command to call Lua scripts, DTS cannot identify whether these Lua scripts are executed on the destination instance. This is because the destination instance does not explicitly return the execution results of Lua scripts during incremental data synchronization.
- When DTS runs the SYNC or PSYNC command to transfer data of the LIST type, DTS does not clear the existing data. As a result, the destination instance may contain duplicate data records.
Permissions required for database accounts
Database | Permission and authorization method |
---|---|
Source ApsaraDB for Redis instance | The database accounts of the source and destination instances must have the read and write permissions. For more information about how to authorize a database account, see Create and manage database accounts. |
Destination ApsaraDB for Redis instance |
Procedure
Result
