Redis Cluster master left without slots after failed upgrade: deciding between forced failover and backup restore

Question

Redis Cluster upgrade failure recovery decision

During a rolling upgrade, a node that fails after accepting writes but before completing the upgrade can leave Redis Cluster in a mixed-version state: a master may have lost its slots while a replica runs a different binary. Redis does not support downgrades, and RDB or AOF files rewritten by the newer version may not be loadable by the older binary. The documentation recommends taking backups before upgrading, but it does not define a deterministic recovery path once the new persistence format has replaced the pre-upgrade files.

The unresolved decision is whether to force a failover to the newer-version replica and continue the upgrade, or restore the pre-upgrade backup and rebuild the topology. The choice affects data loss, slot ownership, and how long the cluster remains mixed-version, but the safe boundary depends on the exact source and target versions and whether the on-disk format has already changed.

Which recovery path is supported when a failed upgrade has already rewritten persistence files? How should slot ownership be handled if the newer-version replica is promoted while another master still runs the old binary? What evidence from release notes or persistence-format checks determines whether the old binary can safely load the current files?

Tasadduq Burney · Answer

Recovery path decisionWhen a Redis Cluster master loses its slots because a rolling upgrade rewrote the on‑disk persistence format, the supported recovery depends on whether an intact pre‑upgrade backup exists outside the upgraded node.Likely explanationThe newer binary writes RDB/AOF in a format that the older binary may reject on startup.Redis does not support in‑place downgrades; attempting to start the old binary against the new files typically yields an “unsupported format” error.Slot ownership is normally reclaimed by the cluster when a master is promoted via failover.Confirmed facts (from release‑note patterns)If a pre‑upgrade RDB/AOF backup was saved elsewhere, you can restore it on a node running the old binary and then re‑assign all 16384 slots.If no such backup exists, the recommended path is to keep the new version and promote a replica that already runs the new binary with CLUSTER FAILOVER (or CLUSTER FAILOVER TAKEOVER if you accept possible data loss for unreplicated writes).After failover, verify that CLUSTER NODES and CLUSTER SLOTS show all slots assigned and that the promoted node owns the recovered master’s slots.Steps for this caseCopy the current persistence file (RDB or AOF) from the upgraded node to a temporary standalone instance running the older Redis binary.Observe the startup log for load errors or “unsupported format” messages.If the old binary loads the file without errors, you may attempt a restore; otherwise, proceed to forced failover.If an intact pre‑upgrade backup is available outside the upgraded node, restore it on a clean node running the old binary, then run CLUSTER SLOTS and CLUSTER SETSLOT to re‑assign every slot.If no backup exists, run CLUSTER FAILOVER (optionally with TAKEOVER) on a replica running the new version. This promotes the replica and assigns the failed master’s slots to it, allowing the upgrade to continue.After either path, run CLUSTER NODES and CLUSTER SLOTS to confirm all 16384 slots are assigned and the cluster is consistent.Missing diagnostic detailDo you have an intact pre‑upgrade RDB/AOF backup stored outside the upgraded node? Answering this determines whether the restore path or the forced‑failover path is the supported recovery.

Redis Cluster master left without slots after failed upgrade: deciding between forced failover and backup restore

Redis Cluster upgrade failure recovery decision

1 answer

Recovery path decision

Likely explanation

Confirmed facts (from release‑note patterns)

Steps for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments