#Limitations and Risks

Unless a limitation is marked as applying to a specific Redis version, it applies to both module generations. See Module generations and version applicability for what distinguishes them.

#Topology limitations

#Both ends of a replication group must run the same Redis version

Replication between Redis 6.0 (legacy module) and Redis 7.2 (new module) is not a designed path — the protocols of the two generations are not compatible. Every member of a replication group must run the same module generation. To move an existing group across generations, see Upgrade a Disaster Recovery Group from Redis 6.0 to Redis 7.2.

Within the new module, all members of a replication group must additionally be running Alauda Cache Service E1 v5.1.0 or later. Links between a v5.1.0 member and an earlier build are not supported.

#The instances at both ends must have the same architecture

Data is synchronized based on Oplogs. The Oplog context has correlation and idempotency, and Oplog data cannot be re-sharded and submitted to different shards. This restriction requires that:

1. The downstream side of a Sentinel instance can only be a Sentinel instance.
2. The downstream side of a cluster instance can only be a cluster instance.
3. The shards of a cluster-mode downstream must be consistent with the upstream.
4. The slot distribution of a cluster-mode downstream must be consistent with the upstream.
5. Cluster mode does not support online synchronization to add or reduce shards.

#A replication group is limited to 16 members

Because service_id is limited to the range [0-15]:

• In Disaster Recovery mode, one upstream can have at most 15 downstream instances. Cascading is not supported — only star distribution, not tree or ring links.
• In Active-Active mode, a group can hold at most 16 members.

#Active-Active mode is available on Redis 7.2 only

Active-Active mode is rejected by admission on Redis 6.0. Disaster Recovery is available on both versions.

#An instance holds at most one upstream connection

An instance may have at most one ActiveRedisConnection — its own upstream link. Fan-out is built by creating a connection in each downstream cluster pointing at the same upstream.

#Configuration limitations

#Replication cannot be turned off, and the Service ID cannot be changed

After replication is enabled, the module writes AUX information records such as the corresponding offset and oplog id in the Redis persistent RDB file; at the same time, there are special synchronization instructions in the master-replica synchronization of the Redis instance. Therefore, to ensure the reliability of the data and the availability of the cluster, the module cannot be unloaded after it is enabled.

For the same reason, spec.activeRedis.serviceID is immutable after creation. Both removing spec.activeRedis and changing serviceID are rejected by admission.

#AOF persistence is not supported (Redis 7.2)

The new module is RDB-only. Its CRDT metadata and the Oplog resume offset persist only in the RDB auxiliary section, which AOF cannot carry. Setting appendonly: "yes" is rejected by admission; if it is somehow set at runtime, the module puts the node into a degraded read-only state in which all writes are rejected — both local application writes and replicated writes from peers.

Use RDB persistence, and see the RDB parameter template recommendation.

#At most 16 databases (Redis 7.2)

customConfig.databases must be <= 16. The module's database addressing is 4-bit and it refuses to load beyond 16 databases, which would leave the pods crash-looping. This is rejected by admission.

#Connection names must be valid module peer names (Redis 7.2)

An ActiveRedisConnection name is used verbatim as the module's peer name, which is stricter than Kubernetes naming: it must start with a letter, and reset, clear, all, and list are reserved words. Names violating either rule are rejected.

#Command limitations

Command Support is the complete reference — which commands are refused with an error, which execute locally and never replicate, which write commands are replicated and how each one resolves a conflict, and what the legacy Redis 6.0 module does differently. This section lists only the constraints that shape a deployment.

#Some commands are not replicated

Pub/sub (PUBLISH/SPUBLISH and the SUBSCRIBE family), every stream command including all consumer-group operations, and the cluster-resharding pair MIGRATE/RESTORE-ASKING execute on the local node and are never replicated. Each datacenter's state for them is independent, and there is no error. If you need cross-datacenter pub/sub or streams, use a message-queue component.

On Redis 7.2, setting a TTL on a stream key is additionally refused, because a replicated expiry would delete peers' unrelated local streams.

#MOVE, SWAPDB, and RESTORE are refused (Redis 7.2)

The new module refuses these three commands outright — in both Disaster Recovery and Active-Active mode — because their effect cannot be made to converge across peers. Applications that use them must be changed before the instance joins a replication group. See Refused with an error.

The legacy Redis 6.0 module does not refuse them.

#FLUSHALL and FLUSHDB are refused while peers are attached (Redis 7.2)

A flush executes locally and is never replicated. Because a flush inside a live replication group would silently diverge the node from its peers — and would discard its dead-key tombstones, allowing a delayed peer write to resurrect a deleted key on that node alone — the new module refuses FLUSHALL and FLUSHDB while the node has any peer attached.

To empty a replication group: remove the connections, flush each isolated instance, then re-create the connections. Alternatively, recreate the instances.

#Operational risks

#Active-Active requires synchronized clocks across datacenters (Redis 7.2)

Conflict resolution is decided by wall-clock time, and the retention floor for tombstones is measured in wall-clock time. A member whose clock runs ahead silently wins conflicts it should have lost, and skew approaching 150 s can let a deleted element reappear. The module measures the skew and alarms on it, but it never blocks a write and never drops a peer — synchronizing the clocks is the operator's responsibility.

Run a time-synchronization daemon (ntpd, chronyd, or the platform equivalent) on every node of every cluster in an Active-Active group, and monitor the alarms. See Clock synchronization for the measurement, the two alarm tiers, and how to confirm that skew caused a particular problem.

#The provided address of the upstream instance must be highly available

The proxy address itself is not highly available. If you expose the proxy via NodePort, place it behind a front-end load balancer to ensure HA; alternatively, use MetalLB to provide a highly available virtual IP for the proxy.

In Active-Active mode on Redis 7.2 the address must expose both the RESP port (6379) and the peer port (7379), and the peer port must not be remapped — the module always advertises its own local peer port for gossip. A Disaster Recovery link uses the RESP endpoint alone.

#Only IP connection addresses are supported (Redis 6.0)

When the downstream instance connects, only <ip:port> connections are supported; domain names are not supported by the legacy module.

In Active-Active mode on Redis 7.2, a DNS name is the recommended form for the announce address and for seed entries, because the module re-resolves it on every dial.

#Replication increases storage pressure — local SSD is recommended

An instance with replication enabled writes Oplogs to storage in real time (fsync is executed once per second); when the Oplog reaches the limited size (3 GB), the Oplog file is cut; the cleaning logic regularly marks unused Oplog slice files and cleans them up in time. Therefore, the above will have the storage logic of Oplog reading and writing and RDB generation at the same time, which will increase the pressure on storage. It is recommended to use local SSD as storage to ensure persistence performance.

#For replication instances, it is recommended to use the RDB parameter template

Using the RDB parameter template, combined with the save parameter, actively triggers snapshots and actively triggers the cleaning of Oplogs, which can ensure that new downstream instance connections can quickly synchronize snapshots.

On Redis 6.0, if you use the AOF parameter template, you still need to set a save parameter to ensure regular RDB persistence, so that the local data is more reliable; but enabling RDB and AOF persistence at the same time has higher performance requirements for storage. Please confirm that you are using local SSD as storage.

On Redis 7.2, AOF is not supported at all — see AOF persistence is not supported.

#Upgrade a live group downstream-before-upstream

When upgrading the Redis version of a group that is actively replicating, upgrade the downstream instances first. A downstream can apply an equal-or-older upstream's Oplog but never a newer one. Bumping an upstream ahead of a live downstream returns an admission warning, and the module holds the affected edge — replication to that downstream pauses until the skew is resolved. A held edge is visible on the connection status through versionState and versionHoldSince.

#After the upstream fails, disconnect from it first

After the upstream fails, before performing a failover, the first thing to do is to disconnect the synchronization link between the downstream and the upstream, to prevent the upstream from suddenly recovering with incorrect data and polluting the downstream side.

#Decommissioning a peer is irreversible

spec.teardownPolicy: Decommission permanently releases the Oplog retention, tombstone garbage-collection, and lag-accounting floors held for a peer. It cannot be changed back to Detach, and a decommissioned peer that later returns is treated as a brand-new peer requiring a full synchronization. Use it only for a datacenter that is gone for good.

#Mesh member removal is not orchestrated (Redis 7.2)

There is no resource-level orchestration for forgetting or unbanning a departed mesh member. Its record ages out of the surviving members' membership on the module's own timers, during which the mesh phase may report Degraded.

#Mesh tuning values are sticky (Redis 7.2)

Only spec.tuning fields greater than zero are pushed to the nodes. Clearing a previously-set field does not reset already-configured pods — they keep the last value until they restart.