Data Transmission Service (DTS) supports two-way data synchronization between Tair instances. This feature is suitable for scenarios such as active geo-redundancy and geo-disaster recovery. This topic describes how to configure two-way data synchronization between Tair instances.
Overview
To use the two-way synchronization feature, you must configure two data synchronization tasks in sequence: a forward data synchronization task and a reverse data synchronization task. The forward data synchronization task performs full data migration and incremental data synchronization. The reverse data synchronization task performs only incremental data synchronization.
Full data migration: DTS allows you to migrate all existing data from a source database to a destination database free of charge.
Incremental data synchronization: After you perform full data migration, DTS can synchronize incremental data from the source database to the destination database in real time. You are charged for incremental data migration based on the duration of the migration instead of the amount of data that is transferred. For more information, see Billable items.
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.
Prerequisites
The source and destination instances are Tair instances.
Tair SSD-based instances do not support two-way synchronization.
If you use a Tair persistent memory-optimized instance as the source instance, set the appendonly parameter to yes.
Precautions
When you run a data migration task, do not scale or change the specifications or endpoint of the source or destination database. Otherwise, the data migration task fails. If the data migration task fails, reconfigure the task to account for the changes. In addition, the data migration consumes resources of the source and destination databases. We recommend that you perform the data migration during off-peak hours.
If the source or destination instance resides in a region outside China, two-way synchronization is supported only between instances within the same region. For example, if an instance resides in the Japan (Tokyo) region, data can be synchronized only within the Japan (Tokyo) region and cannot be synchronized to or from the Germany (Frankfurt) region in two-way synchronization scenarios.
A two-way synchronization instance contains a forward synchronization task and a reverse synchronization task. If you want to synchronize an object in both the forward and reverse synchronization tasks when you configure or reset the instance, the following rules apply:
Only one of the tasks can synchronize both the full data and incremental data of the object. The other task synchronizes only the incremental data of the object.
The source data of the current task can be synchronized only to the destination of the task. The synchronized data is not used as the source data of the other task.
Procedure
Go to the Data Synchronization Tasks page.
Log on to the Data Management (DMS) console.
In the top navigation bar, click DTS.
In the left-side navigation pane, choose .
Click Create Task.
Configure the source and destination databases and click Test Connectivity and Proceed in the lower part of the page. The following table describes the parameters.
Section
Parameter
Description
N/A
Task Name
The name of the task. DTS automatically assigns a name to the task. We recommend that you specify a descriptive name that makes it easy to identify the task. You do not need to specify a unique task name.
Source Database
Select a DMS database instance
If you registered a source database with DMS, you can select the database. After you select the source database, you do not need to enter information about the database. If you did not register a source database with DMS, ignore this option.
Database Type
The type of the source database. Select ApsaraDB for Redis Enhanced Edition (Tair).
Access Method
The access method of the source database. Select Alibaba Cloud Instance.
Instance Region
The region in which the source instance resides.
Replicate Data Across Alibaba Cloud Accounts
Specifies whether to migrate data across Alibaba Cloud accounts. In this example, No is selected.
Instance ID
The ID of the source Tair instance.
Database Password
The password used to connect to the source Tair database.
NoteThis parameter is optional. You can leave the parameter empty.
If you use a custom account, make sure that the account has read permissions. Specify the database password in the <user>:<password> format. For example, if the username of the custom account that you use to log on to the source Tair database is admin and the password is Rp829dlwa, the database password is admin:Rp829dlwa.
Destination Database
Select a DMS database instance
If you registered a destination database with DMS, you can select the database. After you select the destination database, you do not need to enter information about the database. If you did not register a destination database with DMS, ignore this option.
Database Type
The type of the destination database. By default, ApsaraDB for Redis Enhanced Edition (Tair) is selected.
Access Method
The access method of the destination database. Select Alibaba Cloud Instance.
Instance Region
The region in which the destination instance resides.
Instance ID
The ID of the destination Tair instance.
Database Password
The password used to connect to the destination Tair database.
NoteIf you use a custom account, make sure that the account has write permissions. Specify the database password in the <user>:<password> format. For example, if the username of the custom account that you use to log on to the destination Tair database is admin and the password is Rp829dlwa, the database password is admin:Rp829dlwa.
Configure task objects and click Next: Advanced Settings in the lower part of the page. The following table describes the parameters.
Parameter
Description
Synchronization Types
The data synchronization type. Select whether to enable Full Data Synchronization based on your requirements. Incremental Data Synchronization is always selected.
Synchronization Topology
The synchronization topology of the data synchronization task. Select Two-way Synchronization.
Processing Mode of Conflicting Tables
Precheck and Report Errors (default): checks whether keys exist in the destination database.
If keys exist, an error is returned during the precheck and the data migration task cannot be started. If keys do not exist, the precheck is passed.
Ignore Errors and Proceed: skips the Check the existence of objects in the destination database check item. If a key with the same name already exists in the destination database, the key is overwritten.
Source Objects and Selected Objects
Select the objects that you want to synchronize in the Source Objects section and click to move the objects to the Selected Objects section. To remove a selected object, select the object in the Selected Objects section and click to move the object to the Source Objects section.
NoteYou can select databases (DB 0 to DB 255) as the objects that you want to migrate.
Configure the advanced settings and click Next Step: Data Verification in the lower part of the page.
In most cases, you can retain the default settings. For more information, see the "Appendix: Advanced settings" section of this topic.
Configure data verification and click Next: Save Task Settings and Precheck in the lower part of the page.
In most cases, you can retain the default settings. For more information, see Configure data verification.
Perform a precheck, and click Next: Purchase Instance in the lower part of the page.
If Warning or Failed items are generated during the precheck, check the items individually. You can click View Details and troubleshoot the issues. You can also click Confirm Alert Details and ignore the check items. However, issues such as data inconsistency may occur, which may pose risks to your business. For more information, see FAQ. After you complete the preceding operations, perform another precheck.
On the buy page, configure the parameters and click Buy and Start.
(Optional) Select the resource group to which the DTS data migration instance belongs. The default value is default resource group.
(Optional) Select the specifications of the DTS data migration instance. Higher specifications result in faster migration speed and higher costs. The default value is large. For more information, see Specifications of data migration instances.
Read and select the terms of service.
After you purchase the DTS data migration instance, the data migration task starts. You can view the progress of the data migration task on the data migration page.
Wait until the status of the forward data synchronization task becomes Running. Click Configure Task in the Actions column corresponding to the reverse data synchronization task.
Follow the preceding steps to configure the reverse data synchronization task.
If the Success Rate value is displayed as 100%, the configuration is complete. You can click Back.
In the data synchronization task list, if both the forward and reverse data synchronization tasks are in the Running state, two-way data synchronization is successful.
FAQ
Why does the connectivity test fail?
Take note of the following factors when you perform troubleshooting:
The account password is invalid. The password must be in the
user:password
format. For more information, see Logon methods.If the source database is a self-managed database that is deployed in an on-premises data center or on a third-party cloud platform, a network firewall may block access from DTS servers. In this case, manually add the CIDR blocks of DTS servers in the corresponding region to allow access from the servers. For more information, see Add the CIDR blocks of DTS servers.
Why does the migration task fail to run?
If you scale or change the specifications or endpoint of the source or destination database when you run a data migration task, the task fails. In this case, reconfigure the data migration task to account for the changes.
If the destination instance does not have sufficient available memory or the destination instance is a cluster instance whose specific shard has reached the upper memory limit, the DTS data migration task fails due to an out of memory (OOM) error.
If transparent data encryption (TDE) is enabled for the destination instance, you cannot use DTS to migrate data.
Why are data volumes different in the source and destination databases?
If an expiration policy is enabled for specific keys in the source database, these keys may not be deleted at the earliest opportunity after they expire. In this case, the number of keys in the destination database may be smaller than the number of keys in the source database.
When you run the PSYNC or SYNC command to transmit list data, DTS does not perform the FLUSH operation on the existing data in the destination database. As a result, duplicate data may exist.
If the network is interrupted during a full data migration, DTS may perform multiple full data migrations after the connection is reestablished. In this case, DTS automatically overwrites existing keys that have the same name in the destination database. If you perform a delete operation on the source database at this time, the command is not synchronized to the destination database. As a result, the destination database may have more keys than the source database.
Why should I check whether the eviction policy is noeviction?
By default, the maxmemory-policy parameter that specifies how data is evicted is set to volatile-lru for ApsaraDB for Redis instances. If the destination database does not have sufficient memory, data inconsistency may occur between the source and destination databases due to data eviction. In this case, the data migration task does not stop running. To prevent data inconsistency, we recommend that you set the maxmemory-policy parameter to noeviction for the destination database. This way, the data migration task fails if the destination database does not have sufficient memory, but you can prevent data loss in the destination database. For more information about data eviction policies, see What is the default eviction policy of ApsaraDB for Redis?
Why does the
CROSSSLOT Keys in request don't hash to the same slot
error message appear?If the destination instance is a cluster instance, ApsaraDB for Redis does not support cross-slot operations in a single command. We recommend that you perform operations on only one key during data synchronization. This prevents the data synchronization task from being interrupted.
Which commands can be synchronized?
The following commands 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, RESTORE, RPOP, RPOPLPUSH, RPUSH, and RPUSHX
SADD, SDIFFSTORE, SELECT, SET, SETBIT, SETEX, SETNX, SETRANGE, SINTERSTORE, SMOVE, SPOP, SREM, and SUNIONSTORE
ZADD, ZINCRBY, ZINTERSTORE, ZREM, ZREMRANGEBYLEX, ZUNIONSTORE, ZREMRANGEBYRANK, and ZREMRANGEBYSCORE
SWAPDB and UNLINK. These two commands can be synchronized only if the engine version of the source database is Redis 4.0.
XADD, XCLAIM, XDEL, XAUTOCLAIM, XGROUP CREATECONSUMER, and XTRIM
The PUBLISH command 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 database. This is because the destination database does not explicitly return the execution results of Lua scripts during incremental data synchronization.