docs(redis): correct the cross-datacenter replication guides against a live cluster (cherry-pick of #64)

TERMINOLOGY_CANDIDATES.md

@@ -212,3 +212,47 @@ definitive answer needs a register search or counsel.
 | **Active-Passive** | Clear, same class as Active-Active. Considered and not chosen. |
 | **Multi-Active** | **Avoided.** Cockroach Labs presents "Multi-Active Availability" as its own coined term, explicitly contrasted with generic active-active. No ™ and no registration found (their registered mark is COCKROACHDB, Reg. 5307353), but adopting it would read as derivative. |
 | **Mesh** | No trademark issue, but collides with **Service Mesh** in the ACP console. Retained only as a mechanism word. |
+
+## `master` is a forbidden word in the shared glossary (added 2026-09-10)
+
+The shared terms list maps **`master` → `control plane`**, so `doom lint` reports
+`Forbidden word: "master" (control plane)` on any occurrence. The mapping is a
+Kubernetes node-naming rule, and it fires on Redis's own replication role, which
+is genuinely called `master` — `INFO replication` reports `role:master`, and the
+Redis CR carries a `spec.replicas.sentinel.master` field.
+
+Two things make this easy to miss:
+
+* **The local run does not catch it.** `flagWords` are built from the shared
+  terms file, which is fetched over the network; when that fetch is blocked the
+  local `yarn lint` has an empty flag list and reports only unknown words.
+* **CI reports changed lines only,** so the existing occurrences below have never
+  failed a build. They will, on whichever pull request next edits those lines.
+
+Verified against `cspell-lib` with the mapping applied: the hyphenated forms
+**are** flagged (`master-replica` and `master-slave` tokenize to `master`), while
+`mymaster` is not, being a single token.
+
+Pages edited in the cross-datacenter replication pass now use **primary node** /
+**primary-replica pair** and are clean. That is a local choice made to get the
+pass through CI, not a registered term — confirm it, or choose another.
+
+| Still carrying `master` | Line | Kind |
+|:---|:---|:---|
+| `functions/95-disaster-recovery/90-limitations.mdx` | 50 | prose — "master-replica synchronization" |
+| `intro.mdx` | 55 | prose — "master-slave relationships" |
+| `functions/40-accessmethod.mdx` | 51 | prose — "Redis master-replica group" |
+| `functions/75-monitor.mdx` | 35 | prose — alert name "Master-Slave Failover" |
+| `how_to/access/10-sentinel.mdx` | 71 | prose — "master-slave cluster name" |
+
+**Do not rewrite these mechanically.** The same files also carry `master` as an
+identifier, where changing it would be wrong: `spec.replicas.sentinel.master` in
+`functions/10-create-instance.mdx`, and `mymaster` / `MasterName` /
+`setMasterName` / `withSentinelMasterId` in `how_to/access/10-sentinel.mdx` —
+Sentinel's fixed group name and client-library API surface. A blanket
+find-and-replace breaks working examples.
+
+Decisions needed: whether `primary node` is the accepted replacement; whether the
+prose rows above should be converted in one pass; and whether an exemption for
+the Redis role sense belongs in the shared glossary instead, since the product
+will keep meeting the word.

docs/en/functions/95-disaster-recovery/10-intro.mdx

@@ -65,6 +65,8 @@ The `spec.activeRedis.mode` field takes the literal values `peerof` and `mesh`.
 
 The replication module ships in two generations. Which one an instance loads is decided by its Redis version, and the generation determines the feature set, the authentication model, and the peer transport.
 
+Before v5.1 there was only one: Disaster Recovery on Redis `6.0`, introduced in v4.1.0. Redis `7.2` instances and the Active-Active mode arrived with the new module in v5.1, and the legacy generation is now maintained for existing instances only.
+
 | | Redis `6.0` (legacy module) | Redis `7.2` (new module) |
 |:--|:--|:--|
 | Module | Frozen legacy implementation, maintained for existing instances only | Actively developed implementation |
@@ -73,7 +75,7 @@ The replication module ships in two generations. Which one an instance loads is
 | Replicated command set | Smaller — commands introduced after Redis 6.0 are not replicated | Full; see [Command Support](./60-commands.mdx) |
 | Command guards | None — `MOVE`, `SWAPDB`, `RESTORE`, `FLUSHALL`, and `FLUSHDB` are replicated rather than refused | `MOVE`, `SWAPDB`, and `RESTORE` are always refused; `FLUSHALL` and `FLUSHDB` are refused while peers are attached |
 | Peer authentication | None at the module level. The link authenticates as the instance's default account, which the operator binds for you through `spec.activeRedis.redisUserRef` | Mandatory. The instance binds a `RedisUser` through `spec.activeRedis.redisUserRef` — normally its own default account, which must then carry the same password in every datacenter |
-| Peer transport | Proxy Redis Serialization Protocol (RESP) port (`6379`) | The same proxy RESP port (`6379`) — one endpoint carries both transports. Active-Active additionally exposes the module peer port (`7379`) |
+| Peer transport | Proxy Redis Serialization Protocol (RESP) port (`6379`) | The same proxy RESP port (`6379`) — one endpoint carries both transports. Active-Active publishes one additional Service port onto that same endpoint |
 | Persistence | RDB recommended | RDB only — `appendonly=yes` is rejected by admission |
 | Database count | Standard | `databases` must be `<= 16` |
 
@@ -98,14 +100,14 @@ A proxy is deployed for both module generations. Enabling cross-datacenter repli
 | Port | Name | Purpose | Applies to |
 |:-----|:-----|:--------|:-----------|
 | `6379` | `proxy` | RESP endpoint, and the replication transport for both module generations. The proxy tells a peer session apart from a client session and routes it accordingly, so one endpoint carries both. This is the address recorded in mesh seed entries and in an `ActiveRedisConnection`'s `spec.addresses`. | All versions |
-| `7379` | `peer` | The module peer port, aliased onto the same proxy listener. It is added to the proxy Service **only in Active-Active mode**, because a mesh member gossips its own local peer port and something must answer on it. | Redis `7.2`, Active-Active only |
+| *Published by the Service* | `peer` | An alias onto the same proxy listener, added **only in Active-Active mode**. A mesh member gossips a peer address on a port the module fixes itself, and this entry is what answers there. Read the number from the proxy Service rather than assuming one. | Redis `7.2`, Active-Active only |
 
 <Directive type="info" title="A Disaster Recovery link uses one endpoint">
-The proxy Service of a `peerof` instance carries no `7379` port, and none needs to be opened between datacenters. A Disaster Recovery link addresses the proxy RESP endpoint alone — the address recorded in the downstream's `ActiveRedisConnection`.
+The proxy Service of a `peerof` instance publishes only the RESP port, and nothing else needs to be opened between datacenters. A Disaster Recovery link addresses that endpoint alone — the address recorded in the downstream's `ActiveRedisConnection`.
 </Directive>
 
-<Directive type="warning" title="In Active-Active, expose the peer port unchanged">
-When an external load balancer or firewall fronts the proxy of an Active-Active member, it must expose port `7379` as `7379`. The module always advertises its own local peer port for that traffic, so remapping it breaks the mesh. Only the RESP port may be remapped, through `announcePort`.
+<Directive type="warning" title="In Active-Active, publish every proxy port unchanged">
+When an external load balancer or firewall fronts the proxy of an Active-Active member, it must publish every port the proxy Service exposes, each under the same number. The mesh reaches members on a port the module fixes itself and advertises unchanged, so remapping that one breaks the mesh. The RESP port is the exception — it may be remapped, through `announcePort`.
 </Directive>
 
 ### Instance ID: Service ID