#Set Up Active-Active Replication

Setting up Active-Active replication has two parts: enabling Active-Active mode on each Redis instance, and creating one ActiveRedisMesh per member so that the members can find each other. For how the mode works — discovered membership, the two ports, conflict resolution, and the clock requirement — read Architecture first. For how it compares with Disaster Recovery, see Choosing a mode.

#Prerequisites

• Every member runs Redis 7.2.
• Each member has a distinct serviceID in the range [0-15].
• Each member's proxy is reachable from every other member on both port 6379 (RESP, used by seeds) and port 7379 (peer port, which carries both gossip and replication).
• The system clocks of all members are synchronized, through a time-synchronization daemon (ntpd, chronyd, or the platform equivalent) on every node of every cluster in the group. This is a hard prerequisite, not a recommendation — see Clock synchronization.

#Step 1: Create the peer-auth credential in each datacenter

Every peer link in an Active-Active group authenticates, and every member must present the same username and the same password value. Create the credential in each datacenter before enabling the mode. This is the same credential Disaster Recovery uses; if these instances already carry one, skip to Step 2.

# The dedicated password secret for the peer-auth account
$ kubectl -n default create secret generic s72-dc1-peer-secret --from-literal=password='Peer@Repl123'

# The peer-auth RedisUser
$ cat << EOF | kubectl -n default create -f -
apiVersion: redis.middleware.alauda.io/v1
kind: RedisUser
metadata:
  name: s72-dc1-peer
spec:
  accountType: custom
  arch: sentinel
  redisName: s72-dc1
  username: aapeerrepl
  passwordSecrets:
  - s72-dc1-peer-secret
EOF

spec.arch must match the architecture of the referenced instance (sentinel, cluster, or standalone).

Wait for the user to be applied:

$ kubectl -n default get redisusers s72-dc1-peer
NAME           INSTANCE   USERNAME     PHASE     AGE
s72-dc1-peer   s72-dc1    aapeerrepl   Success   12s

#Step 2: Enable Active-Active mode on each instance

Members must advertise an externally-routable address, because a peer re-resolves it on every dial. This is the announceAddress, set on the proxy Service configuration.

$ kubectl -n default patch redis s72-dc1 --type=merge --patch='
spec:
  activeRedis:
    serviceID: 0
    mode: mesh
    redisUserName: s72-dc1-peer
    proxy:
      service:
        type: LoadBalancer
        announceAddress: redis-dc1.example.com
        announcePort: 6379
'

#Step 3: Create an ActiveRedisMesh in each cluster

Each Kubernetes cluster owns one ActiveRedisMesh for its local instance. spec.seeds names the externally-routable proxy RESP addresses of members in other datacenters.

$ cat << EOF | kubectl -n default create -f -
apiVersion: redis.middleware.alauda.io/v1alpha1
kind: ActiveRedisMesh
metadata:
  name: mesh-dc1
spec:
  instance: s72-dc1
  seeds:
  - redis-dc2.example.com:6379
  - redis-dc3.example.com:6379
EOF

#Seed syntax

A seed is host:port, where the port is the remote proxy's RESP endpoint — normally 6379. An optional @peer-port suffix overrides the peer port when an external load balancer remaps it; when the suffix is omitted the operator appends the conventional 7379. The operator normalizes the list before injecting it, so redis-dc2.example.com:6379 becomes redis-dc2.example.com:6379@7379.

The operator injects the normalized set on every node, replicas included, so the mesh auto-starts on every pod. Restart and failover re-entry are therefore zero-touch.

#Optional fields

#Step 4: Verify convergence

$ kubectl -n default get activeredismesh
NAME       INSTANCE   PHASE     MEMBERS   ALIVE   AGE
mesh-dc1   s72-dc1    Healthy   3         3       2m

$ kubectl -n default get activeredismesh mesh-dc1 -o yaml
...
status:
  phase: Healthy
  instance: s72-dc1
  epoch: 7
  memberCount: 3
  aliveCount: 3
  suspectCount: 0
  deadCount: 0
  fleetFloorVersion: "7.2"
  versionConverged: true
  members:
  - uid: 9f2c1a...
    serviceID: 0
    shardID: 0
    address: redis-dc1.example.com
    state: alive
    epoch: 7
    clockOffsetMs: 2
    version: "7.2"
    moduleVersion: 10
  - uid: 4b81d3...
    serviceID: 1
    shardID: 0
    address: redis-dc2.example.com
    state: alive
    epoch: 7
    clockOffsetMs: -5
    version: "7.2"
    moduleVersion: 10

#Mesh phases

#Member states

A member is alive, suspect, or dead — see Membership lifecycle.

clockOffsetMs is each member's clock offset relative to this instance, in milliseconds. See Clock synchronization.

#Version fields

status.fleetFloorVersion reports the lowest Redis version across non-dead members that report a known version — the feature ceiling for the whole mesh. status.versionConverged is true once every non-dead member runs the same Redis and module version.

#Next steps

Day-2 work — monitoring clock skew, adjusting the gossip timers, and adding or removing members — is covered in Operations.