docs(redis): correct the cross-datacenter replication API surface

[chideat]

Validated docs/en/functions/95-disaster-recovery/ against a live business cluster (operator v5.1.0-rc.43.g2e4ef16f, an ancestor of release-5.1 whose only intervening commits are e2e tests) and against release-5.1 source. Several documented API names and procedures no longer match the product, and the setup guides could not be followed as written.

Peer authentication now binds the default account

Per 207d1c3c (accept the default account as a peer-auth credential) and 77851bdc. Both setup guides used to open by creating a dedicated custom RedisUser with the username aapeerrepl and its own password Secret. aapeerrepl was removed from the product together with secretName, its only password source, and never shipped in a released build.

Step 1 of each guide now confirms the default-account RedisUser — drc-acl-<instance>-default on cluster, rfr-acl-<instance>-default otherwise — which needs no provisioning, and states the requirement that follows: default passwords are generated per instance, so every member of a group must be given the same one. Binding a custom account stays documented as the narrower alternative.

API corrections

Documented	Actual	Evidence
spec.activeRedis.redisUserName	the field is redisUserRef	dry-run: Warning: unknown field + patched (no change) — a silent no-op
ActiveRedisConnection.spec.secretName	removed	dry-run: strict decoding error: unknown field "spec.secretName" — the Redis 6.0 procedure was unexecutable
7.2 replicates over a dedicated peer port 7379	the port is added to the proxy Service only in mesh mode	internal/builder/activeredis/service.go:73 if isNew && as.Spec.IsMeshMode(); the live peerof instance's proxy Service has only 6379, and replicates fine
spec.peerPort defaults to 7379	no schema default; defaults to the port of addresses[0]	api/middleware/redis/v1alpha1/activeredisconnection_types.go:68-80

The upgrade guide's prerequisite to open 7379 between datacenters was for a port nothing listens on in Disaster Recovery mode.

Also corrected

• The peer-auth RedisUser may be a custom or a default account; only system is refused (ResolvePeerAuthCredential).
• The password-Secret exclusivity rule applies when either RedisUser involved is bound as a peer-auth credential, not to any two custom users (validateSecretExclusivity).
• The automatic 6.0 path binds the existing default-account RedisUser rather than minting one — redis_peerauth_provision.go:29-76 says "Nothing is provisioned".
• The failover sample no longer shows pause: true as an upstream failure; a paused connection is itself a cause of disconnected shards.
• The Redis 6.0 downstream example no longer reuses the upstream's serviceID directly under a warning that it must be unique.
• The Redis 6.0 procedure gains a step to wait for the operator-written binding, which the connection would otherwise outrun.

Verification

• Corrected examples re-validated by server-side dry-run: only business rules (already-exists, missing placeholder instance) block them; schema passes.
• End-to-end: a key written on the upstream was readable on the downstream within 3 s, then deleted. Everything else was dry-run; the cluster was left clean.
• yarn lint: 0 errors, 0 warnings. In-repo anchor check: 0 unmatched across 51 files.
• Terminology candidates recorded in TERMINOLOGY_CANDIDATES.md — 4 terms await human confirmation.

Not verified here

Web Console procedures, cross-datacenter/LoadBalancer reachability, Redis 6.0 runtime behaviour (no 6.0 instance available), mesh convergence, failover and teardown. None of these are marked as verified in the docs.

Follow-ups outside this repo

• internal/webhook/middleware/v1/validation/validation.go:194 warns about spec.activeRedis.mesh.announceAddress, a path that does not exist; the field is spec.activeRedis.proxy.service.announceAddress.
• The defaultActiveRedisPeerAuthBinding doc-comment at redis_webhook.go:465-477 still describes minting a RedisUser and password Secret from the connection credential, which ensureAutoPeerAuthUser no longer does. That stale comment is the likely origin of the aa-peer/aapeerrepl story in these docs.

master carries the same disaster-recovery pages (from #51) and needs a cherry-pick of this alongside the still-open #58.

🤖 Generated with Claude Code

[cloudflare-workers-and-pages]

Deploying alauda-redis with    Cloudflare Pages

Latest commit:	2fc1146
Status:	✅  Deploy successful!
Preview URL:	https://8691b63b.alauda-redis.pages.dev
Branch Preview URL:	https://docs-dr-api-corrections.alauda-redis.pages.dev

View logs