[chideat]

Important

Merge after redis-operator 5.1.2 is released. The guide tells Redis 7.x users to run a redis-operator release later than 5.1.1, and none is published yet.

Rewrites How_to_Migrate_Redis_Across_Clusters.md, which covered only platform 3.8 to 3.16, from tests on ACP 4.4 with redis-operator 5.1 and Redis 6.0 and 7.2.

Why

On 4.x the guide was wrong in several places:

• It said Redis 7.x is not supported at all. A Redis 7.x target works; only a 7.x source failed, and it now works on redis-operator releases later than 5.1.1.
• It required an image from a table that stops at 3.16. redis-operator 5.1 fills in the image itself.
• It pointed to a Grafana dashboard and metric names that do not exist on 4.x.
• It did not mention behaviour that silently loses data or fails: keys outside database 0 are skipped on a cluster target, the mymaster@ address cannot authenticate to Sentinel nodes that have their own password, and most edits to a running RedisShake resource are ignored.

What changed

• Applicable versions: 4.x with redis-operator 5.1 or later. The 3.x image table, dashboard notes and known issue move to an appendix, unchanged.
• Choose a Migration Mode: when to use sync and when to use rump, by Redis version, and the log signature that shows a release without Redis 7.x support.
• Addresses: the format for each architecture and role, the external access that a cross-cluster migration needs, and how to connect to the data nodes when Sentinel has its own password.
• Monitoring and verification: the real metric names and how to read them, and how to compare key counts.
• Changing a running migration: which fields take effect and which are ignored.
• Troubleshooting for six symptoms, and the known issue with XGROUP commands on a cluster target.

How it was verified

On ACP 4.4 test clusters with redis-operator 5.1. Each migration was checked with a content digest of every key (value, type and TTL presence, including stream entries, consumer groups and pending entries), after the full copy and again after incremental writes. A negative control confirmed that the digest catches a one-byte change.

Scenario	Result
sync, 6.0 to 6.0, all five source and target architecture combinations	Pass
sync, 6.0 to 7.2, all five combinations	Pass
sync, 7.2 to 7.2, all five combinations, RedisShake image of redis-operator 5.1.1 and earlier	Fails with invalid RDB version number 11, 9, as the guide now says
rump, 7.2 to 7.2, all five combinations	Pass; a write made after the copy finished does not reach the target
sync, 7.2 to 7.2, all five combinations, redis-operator built from the 5.1 release branch after 5.1.1, image chosen by the operator	Pass. Before the upgrade, the same cluster on 5.1.1 failed the Standalone to Sentinel case with the error above; the operator was then upgraded in place through OLM. 6.0 to 6.0 and 6.0 to 7.2 (Sentinel to Sentinel) also pass with the new image

Also checked: Sentinel nodes with their own password (fails with NOAUTH; connecting to the data nodes passes), passwords with every special character the platform allows, a key in database 3 (kept on a Sentinel target, silently missing on a cluster target), edits to a running resource, the metric values at steady state, and cleanup when the resource is deleted.

Carried over from the original without new tests: the capacity rules and the network stability note.

The Chinese page is translated by hand in this PR, because the pull request check compares it with the English page the branch changes. Its sourceSHA matches the English file, so the translation run on main keeps it. The two headings the page links to have explicit ids, so those links work in both languages.