Type | Description |
Source database limitations | To ensure sync quality, Data Transmission Service (DTS) inserts a key with the prefix DTS_REDIS_TIMESTAMP_HEARTBEAT into the source database to record update timestamps. If the source database uses a cluster architecture, DTS inserts this key into each shard. The key is filtered out during synchronization and expires after the sync task ends. If the source instance is a read-only instance or the DTS account does not have write (SETEX) permissions, the reported latency may be inaccurate. To ensure link stability, increase the value of the repl-backlog-size parameter in the redis.conf configuration file. If some keys in the source database use an expiration (expire) policy, the number of keys in the destination database may be less than in the source database. This can happen because expired keys are not always deleted promptly. You can check the number of keys by running a command such as `info`. Limitations apply when you synchronize data from a Basic Edition Redis instance to a cluster architecture Redis instance. A Redis cluster allows a single command to operate on only one slot. If you run a multi-key operation on the source instance and the keys are not in the same slot or involve multiple slots, the following error occurs: CROSSSLOT Keys in request don't hash to the same slot
During DTS synchronization, run only single-key operations to prevent link interruptions. If the source instance is a Tair (Enterprise Edition) instance whose Storage Medium is Persistent Memory, ensure that the appendonly parameter is set to yes. For more information, see Procedure. If the source is a child instance of a Tair (Enterprise Edition) instance with the Global Distributed Cache feature, DTS can synchronize data only from the selected child instance. This is due to the limitations of the instance and feature. Data from other child instances cannot be synchronized.
|
Other limitations | If the source instance is a self-managed Redis instance, set the repl-timeout parameter, which specifies the replication timeout period between the slave and master nodes, to 600 seconds. You can use the command config set repl-timeout 600. If the source database contains a large volume of data, increase the value of the repl-timeout parameter as needed. During synchronization, operations such as scale-out, scale-in, instance configuration changes, or endpoint and port changes on the source or destination Redis instance can interrupt the sync task. This is because DTS cannot obtain continuous log data and correct connection information. If an interruption occurs, clear the data that has been synchronized to the destination Redis instance before you reconfigure the task. This ensures data consistency. When the source or destination instance is a self-managed Redis instance (the Access Method is not Alibaba Cloud Instance), if its connection address changes during synchronization in scenarios such as an instance migration or an active/standby switchover, the sync task may experience retries, delays, failures, or even data inconsistency. Promptly check the status of the sync task. If the DTS task experiences issues such as retries, delays, or failures, reconfigure the sync task. After an instance migration, such as a failover, is triggered on the destination Redis instance, data may be written only to memory and not to the secondary database. This can cause data loss. Keep the source and destination database versions the same, or synchronize from an earlier version to a later version to ensure compatibility. If you synchronize from a later version to an earlier version, compatibility issues may occur. During initial full data synchronization, DTS consumes some read and write resources of the source and destination databases. This may increase the database load. Before you start data synchronization, evaluate the performance of the source and destination databases. Perform data synchronization during off-peak hours. During DTS synchronization, do not write data to the destination database from any source other than DTS. Otherwise, data inconsistency between the source and destination databases will occur. If the destination instance has a cluster architecture and one of its shards reaches the memory limit, or if the destination instance has insufficient storage space, the DTS task will fail due to an out of memory (OOM) error. 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 Transparent Data Encryption (TDE) is enabled for the source or destination instance, you cannot use DTS to synchronize data. If any of the following situations occur during data synchronization, full data may be re-synchronized to the destination, which can cause data inconsistency. A transient connection occurs on the source or destination Redis instance, causing the sync to fail to resume from a breakpoint. A failover occurs on the source or destination Redis instance. The endpoint of the source or destination Redis instance changes. The sync objects of the DTS instance are modified.
If your Tair (Redis OSS-compatible) instance has TLS (Transport Layer Security) encryption enabled, you must connect to DTS using an SSL-encrypted (TLSv1.3 is not supported). Currently, you cannot use the Alibaba Cloud Instance method to connect to a Tair (Redis OSS-compatible) instance that has SSL enabled. If a sync instance includes both a full data sync task and an incremental data sync task, DTS may re-run both tasks after the instance restarts. If an instance fails, DTS helpdesk will try to recover the instance within 8 hours. During the recovery process, operations such as restarting the instance and adjusting parameters may be performed.
Note When parameters are adjusted, only the parameters of the DTS instance are modified. The parameters of the database are not modified. The parameters that may be modified include but are not limited to those described in Modify instance parameters.
|