|
Type
|
Description
|
|
Source database limitations
|
-
DTS inserts a key prefixed with DTS_REDIS_TIMESTAMP_HEARTBEAT into the source database to record update timestamps. For clusters, this key is inserted into each shard. The key is filtered during synchronization and expires after the task completes.
-
If the source database is a read-only instance or the DTS account does not have write (SETEX) permissions, the reported latency may be inaccurate.
-
To ensure connection stability, increase the value of the repl-backlog-size parameter in the redis.conf file.
-
Do not run FLUSHDB or FLUSHALL on the source database. This causes data inconsistency between the source and destination.
-
If some keys in the source database have an expiration policy, they may not be deleted immediately upon expiry. The key count in the destination (viewable with info) may be lower than in the source.
-
When synchronizing from a standalone to a cluster Redis instance, Redis clusters allow a single command to operate on only one slot. Multi-key operations on keys in different slots return the following error: CROSSSLOT Keys in request don't hash to the same slot
To prevent task interruptions, perform only single-key operations during DTS synchronization.
-
Two-way synchronization is supported only between Tair (Enterprise Edition) instances. Supported instances include:
-
The two-way synchronization feature for Tair (Enterprise Edition) is currently in beta for connections that use Express Connect, VPN Gateway, or Smart Access Gateway. If you require this feature, please submit a ticket to contact us.
-
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 as described in Steps.
-
If the source Redis instance uses extended modules such as RedisJSON, RediSearch, RedisBloom, RedisTimeSeries, RedisGraph, RedisAI, RedisGears, RedisCell, RediSQL, redis-tdigest, or RedisCompat, DTS cannot parse their RDB storage formats and the task fails.
-
If the source is a child instance of a Tair (Enterprise Edition) Global Distributed Cache, DTS can synchronize data only from the selected child instance. Data from other child instances in the group is not synchronized.
Note
To synchronize data from other child instances in the Global Distributed Cache group, join the DTS customer communication group on DingTalk (Group ID: 116655009709) for assistance. You can download the DingTalk client from the DingTalk client download link.
|
|
Other limitations
|
-
Operations on the source or target Redis instance during synchronization, such as scaling, changing specifications, migrating availability zones, or changing the endpoint or port, can interrupt the task. DTS cannot obtain continuous log data or correct connection information. If this occurs, clear the synchronized data from the target before you reconfigure the task.
-
If the source or destination is a self-managed Redis (where Access Method is not Alibaba Cloud Instance) and its endpoint changes during synchronization (for example, due to a migration or primary/standby switchover), the task may experience retries, latency, or failures, and data inconsistency may occur. Monitor the task status and reconfigure it if abnormalities persist.
-
During an instance migration on a target Redis instance, such as a primary/standby switchover, data may be written only to memory and not replicated to the standby instance, which can lead to data loss.
-
To ensure compatibility, use the same version for the source and destination databases or synchronize from an earlier version to a later one.
-
During initial full data synchronization, DTS consumes read and write resources on the source and destination, which may increase load. Evaluate database performance beforehand and synchronize 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 result.
-
If a table is synchronized by both the forward and reverse tasks, and the forward task includes both full and incremental data, the reverse task synchronizes only incremental data for that table.
-
If the destination instance is a cluster and one of its shards reaches its memory limit, or if the destination instance runs out of storage space, the DTS task fails due to an out-of-memory (OOM) error.
-
If the destination database runs out of memory and triggers data eviction, data may become inconsistent between the source and destination. This occurs because the default data eviction policy (maxmemory-policy) for Tair (Redis OSS-Compatible) is volatile-lru. However, this does not affect normal task operation.
To prevent this issue, we recommend setting the data eviction policy for the destination database to noeviction. With this policy, if the destination runs out of memory, write operations fail, the task stops, and no data is lost to eviction.
-
DTS does not currently support synchronization if Transparent Data Encryption (TDE) is enabled on the source or destination instance.
-
Full data may be re-synchronized to the destination and cause data inconsistency under the following conditions:
-
A transient connection interruption occurs on the source or destination Redis instance, and resumable transmission fails.
-
A primary/standby switchover or a failover occurs on the source or destination Redis.
-
The endpoint of the source or destination Redis instance changes.
-
The synchronized objects of the DTS instance are modified.
-
If a Tair (Redis OSS-Compatible) instance has Transport Layer Security (TLS) encryption enabled, you must connect to it by using the SSL-encrypted method in DTS. TLSv1.3 is not supported. You cannot connect to an SSL-enabled Tair (Redis OSS-Compatible) instance by setting the Alibaba Cloud Instance to Alibaba Cloud Instance.
-
Restarting a synchronization instance that includes both full and incremental tasks may cause DTS to rerun both.
-
Restarting a synchronization instance may cause commands to execute more than once, leading to data inconsistency if non-idempotent commands such as INCRBY and LPUSH exist, or if full data re-synchronization is triggered.
-
If a task fails, DTS support staff will attempt to restore it within eight hours. During restoration, they may restart the task or adjust its parameters.
Note
Only DTS task parameters are modified—not database parameters. Parameters that may be adjusted include those listed in Modify instance parameters.
|