#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 has an externally-routable announceAddress set explicitly — see Step 2. Nothing defaults it to a cross-datacenter address, and admission only warns, so a member left without one advertises an address its peers cannot reach.
• Each member's proxy endpoint is reachable from every other member on every port its proxy Service publishes, each under its own number — not only the announced one.
• 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: Provision the peer-auth credential in each datacenter

Every peer link in an Active-Active group authenticates, and every member must present the same credential: a member accepts an inbound peer only when the username it presents equals the member's own peer-auth username and the password validates against Redis ACL. Each instance binds that credential through spec.activeRedis.redisUserRef, which names a RedisUser object in the instance's own namespace.

Whichever account you bind, it must:

• reference the local instance — a RedisUser that targets another instance is refused;
• be a custom or a default account; a system account is always refused;
• own a password Secret carrying a password key;
• reach status.phase: Success — the binding is rejected until then;
• carry the same username and the same password value in every datacenter.

#A dedicated account (recommended)

Create a custom RedisUser for this purpose in every datacenter. It narrows what the credential grants — anything holding the default password can otherwise act as a mesh peer — and lets the replication credential be rotated independently of the instance password.

Password Secrets are one-to-one with RedisUser objects, so each datacenter needs its own Secret object; what has to match across datacenters is the password value, not the Secret name.

The password is policy-checked at admission: 8 to 32 characters, and it must mix letters, digits and special characters. A value that does not qualify is rejected when the RedisUser is created, with password should consists of letters, number and special characters.

$ cat << EOF | kubectl -n default create -f -
apiVersion: v1
kind: Secret
metadata:
  name: aa-peer-auth-dc1
stringData:
  password: <the shared peer-auth password>
---
apiVersion: redis.middleware.alauda.io/v1
kind: RedisUser
metadata:
  name: aa-peer-auth-s72-dc1
spec:
  accountType: custom
  arch: sentinel
  redisName: s72-dc1
  username: aa-peer
  aclRules: +@all ~*
  passwordSecrets:
  - aa-peer-auth-dc1
EOF

Wait for the account before binding it:

$ kubectl -n default get redisusers aa-peer-auth-s72-dc1
NAME                   INSTANCE   USERNAME   PHASE     AGE
aa-peer-auth-s72-dc1   s72-dc1    aa-peer    Success   1m

#The instance's default account (fallback)

The instance's own default account may be bound instead — this is the same credential Disaster Recovery uses, so if these instances already carry a binding, you can skip to Step 2.

peer-auth RedisUser "rfr-acl-s72-dc1-default" has no password secret: the module rejects credential-less peers

The default-account RedisUser is named after the instance:

$ kubectl -n default get redisusers rfr-acl-s72-dc1-default
NAME                      INSTANCE   USERNAME   PHASE     AGE
rfr-acl-s72-dc1-default   s72-dc1    default    Success   3m

#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
    redisUserRef: aa-peer-auth-s72-dc1
    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 announced endpoints of members in other datacenters — the announceAddress and announcePort those members were given in Step 2.

set mesh config on pod rfr-s72-dc1-0: ERR Unknown option or number of arguments for CONFIG SET
- 'activeredis.mesh-seeds'; shard 0 mesh info: ERR unknown command 'as.mesh'

$ 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 — the remote member's announceAddress:announcePort, written exactly as that member advertises itself. It is an externally-routable endpoint, so when a load balancer or VIP fronts that member's proxy, the seed is the load balancer's address and port, not the in-cluster proxy Service. Write the pair verbatim: a member recognizes its own entry by comparing a seed's address and port with the pair it announces, and a mismatch defeats that self-skip.

Write seeds as plain host:port and let the operator complete them. It normalizes the list into the module's internal seed grammar before injecting it, so CONFIG GET activeredis.mesh-seeds reports each entry in a longer form than the one you wrote. That completion is required for a seed to be usable at all, and there is nothing in it for you to set.

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
  memberCount: 3
  aliveCount: 3
  fleetFloorVersion: "7.2"
  versionConverged: true
  members:
  - uid: 9f2c1a...
    serviceID: 0
    shardID: 0
    state: alive
    version: "7.2"
  - uid: 4b81d3...
    serviceID: 1
    shardID: 0
    address: redis-dc2.example.com:6379
    state: alive
    clockOffsetMs: -5
    version: "7.2"
    moduleVersion: 10
  - uid: 07d65b...
    serviceID: 2
    shardID: 0
    address: redis-dc3.example.com:6379
    state: alive
    clockOffsetMs: -2
    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.