Category | Description |
Limits on the source database | To ensure the synchronization quality, Data Transmission Service (DTS) adds a key prefixed with DTS_REDIS_TIMESTAMP_HEARTBEAT to the source database. This key is used to record the time when data is synchronized to the destination database. If the source database is deployed in a cluster architecture, DTS adds this key to each shard. The key is filtered out during data synchronization. After the data synchronization task is complete, the key expires. If the source database is a read-only database or the source database account that is used to run the data synchronization task does not have the permissions to run the SETEX command, the reported latency may be inaccurate. To ensure the stability of data synchronization, we recommend that you increase the value of the repl-backlog-size parameter in the redis.conf file. If an expiration policy is enabled for specific keys in the source database, these keys may not be deleted in a timely manner after they expire. Therefore, the number of keys in the destination database may be smaller than that in the source database. You can run the info command to view the number of keys in the destination database. Limits on synchronizing data from a standalone Tair (Redis OSS-Compatible) instance to an Tair (Redis OSS-Compatible) cluster instance: Each command can be run only on a single slot in an Tair (Redis OSS-Compatible) cluster instance. If you perform operations on multiple keys in the source database and the keys belong to different slots, the following error occurs: CROSSSLOT Keys in request don't hash to the same slot
We recommend that you perform operations on only one key during data synchronization. Otherwise, the data synchronization task is interrupted. If the source database is a Tair cloud-native persistent memory-optimized instance, you must set the appendonly parameter to yes for the instance.
|
Other limits | The timeout period for data replication between the master and replica nodes in the source database is specified by the repl-timeout parameter. If the source database is a self-managed Redis database, we recommend that you run the config set repl-timeout 600 command to set this timeout period to 600 seconds. If the source database contains a large amount of data, you can increase the value of the repl-timeout parameter based on your business requirements. During data synchronization, if the number of shards in the source Redis database is increased or decreased, or if you change the database specifications, such as scaling up the memory capacity, you must reconfigure the data synchronization task. To ensure data consistency, we recommend that you clear the data that has been synchronized to the destination Redis database before you reconfigure the task. If the source or destination database is a self-managed Redis database and the endpoint of the self-managed Redis database is changed during data synchronization, you must reconfigure the data synchronization task. To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur. During initial full data synchronization, DTS uses read and write resources of the source and destination databases. This may increase the loads on the database servers. Before you run a task to synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. Data inconsistency between the source and destination databases may occur if data from other sources is written to the destination database during data synchronization. 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). By default, the maxmemory-policy parameter that specifies how data is evicted is set to volatile-lru for Tair (Redis OSS-compatible) instances. If the destination instance has insufficient memory, data inconsistency may occur between the source and destination instances due to data eviction. In this case, the data synchronization task does not stop running. To prevent data inconsistency, we recommend that you set maxmemory-policy to noeviction for the destination instance. This way, the data synchronization task fails if the destination instance has insufficient memory, but data loss can be prevented for the destination instance. If the transparent data encryption (TDE) feature is enabled for the source or destination database, you cannot use DTS to synchronize data. During data synchronization, if resumable upload fails due to transient connections that occur on the source Redis database, full data may be re-synchronized to the destination database. This may cause data inconsistency between the source and destination databases. If Transport Layer Security (TLS) encryption is enabled for the source or destination Tair (Redis OSS-Compatible) instance, you must select SSL-encrypted for the instance when you configure the DTS task. TLSv1.3 is not supported. If SSL encryption is enabled for the source or destination Tair (Redis OSS-Compatible) instance, you cannot set Access Method to Alibaba Cloud Instance for the instance.
|