How to Upgrade a Redis Cluster With Zero Downtime

Published on
July 7, 2026

Upgrading a Redis Cluster sounds like it should be the easy part - install the new binary, restart, done. On a single server that's roughly true. On a live cluster serving production traffic, the binary swap is trivial and everything around it is the hard part: in-flight writes, the failover window when a primary restarts, slot ownership during the transition, and clients that need to refresh topology without dropping requests. This guide covers the two strategies that matter, how to decide between them, and how to run either one with no client-visible downtime.

Why a Cluster Upgrade Is Riskier Than It Looks

A Redis Cluster spreads its keyspace across 16,384 hash slots, with each slot owned by a primary that has one or more replicas and automatic failover between them. That design is exactly what makes a careless upgrade dangerous:

  • Restarting a primary drops its connections. Until a replica is promoted, the slots that primary owned are unavailable. Do this on every node in sequence without coordination and you stack up many small outages.
  • In-flight writes can be lost if you restart a primary before its replica has caught up, or if you promote a replica that's behind.
  • Clients cache the cluster topology. When ownership moves, a client that doesn't refresh promptly sends commands to the wrong node and gets MOVED/ASK redirects - extra latency at best, errors at worst.
  • Major versions introduce breaking changes. Jumping across a major version can change command behavior, ACL semantics, or which modules ship in the box. The upgrade isn't done when the version string changes; it's done when your application still behaves correctly against it.

There are two ways to absorb all of that without your users noticing.

Two Strategies, and How to Choose

Rolling in-place upgrade - upgrade the existing nodes one at a time, leaning on the cluster's own replica failover to keep slots available throughout. No second cluster, no extra tooling. This is the right call for minor and patch bumps where the topology, OS, and instance types stay the same and the risk of a bad upgrade is low.

Blue-green upgrade - stand up a brand-new cluster on the target version, replicate the live data into it, then atomically switch clients over. More moving parts, but it gives you a clean, instant rollback because the old cluster is untouched until you decommission it. This is the right call for major version jumps, OS or instance-type changes, topology changes (more shards, different node sizing), or any upgrade where a failed in-place attempt would be unacceptable.

A rough rule: if you'd be comfortable restarting each node in place and the version gap is small, roll. If the jump is large or the blast radius of a mistake is high, go blue-green. Both keep serving traffic while the new version comes online - the rolling path uses Redis's own replication (a newer replica can sync from an older primary across an adjacent major version), and the blue-green path uses a replication tool to bridge the two clusters.

Strategy A - Rolling In-Place Upgrade

This is the standard path and the one most people mean by "upgrade the cluster." Done in the right order, the cluster never loses ownership of a slot for more than the moment a graceful failover takes.

Pre-Flight

Before touching a single node:

  • Back up every node. Run BGSAVE (or confirm a recent RDB/AOF) on each primary so you have a restore point.
  • Read the release notes for every major version you're crossing. This is where breaking changes live - see the dedicated section below.
  • Check for deprecated or changed commands your application uses, and confirm your client library supports the target version.
  • Rehearse on a canary loaded with production-like data. An upgrade that works on an empty cluster tells you very little.
Execute, Shard by Shard

The ordering principle is simple: never upgrade a node while it's the active primary for live slots. Always upgrade a replica, then make it primary, then upgrade the node it displaced.

For each shard:

  1. Upgrade a replica first. Stop Redis on the replica, install the new version, start it back up. It resyncs from the (still older) primary - a newer replica reading from an older primary is the supported direction.
  2. Confirm it's caught up before going further: 
    redis-cli -c -h <replica-host> -p <port> INFO replication
    Wait for master_link_status:up and a current offset.
  3. Promote the upgraded replica with a graceful, cluster-aware failover issued on the replica you want promoted: 
    redis-cli -c -h <replica-host> -p <port> CLUSTER FAILOVER
    CLUSTER FAILOVER coordinates with the current primary so the handover happens with no lost writes and no visible gap.
  4. Upgrade the old primary, which is now a replica. Stop, install, start; it rejoins and resyncs from the new (upgraded) primary.

Repeat for every shard. Throughout, the cluster always has a healthy primary for each slot, so reads and writes keep flowing.

Where Rolling Runs Out of Road

In-place upgrades are convenient precisely because they're irreversible-ish: once a node is upgraded and serving, backing out means another restart cycle. If the new version misbehaves under real traffic, your rollback is slow and noisy. And in-place can't help you change topology or move to new hardware. When any of that matters, reach for blue-green.

Strategy B - Blue-Green Upgrade With a Parallel Cluster

Here you build the new version alongside the old one, mirror the data live, and flip clients over in a single command. Because the old cluster keeps running untouched until you're satisfied, rollback is just "don't flip" - or "flip back."

1. Stand Up the Target Cluster

Provision a fresh Redis Cluster on the target version with the topology you want - same shape for a straight upgrade, or a new one if you're resharding at the same time.

2. Replicate Live Data Into It

You need something to stream the existing keyspace into the new cluster while the application keeps writing to the old one. Two solid open-source options:

Both run in either Psync or Scan mode:

  • Psync mode makes the tool behave like a replica: it connects to each source primary with PSYNC, receives a snapshot, then tails the live command stream, including partial resync if it briefly disconnects. Use this whenever your source allows it. You configure this on the tool, not on the cluster nodes - you don't (and in cluster mode can't) point one cluster at another with REPLICAOF; the tool is what emulates a replica and replays the stream into the new cluster. You can watch the source-side progress with INFO replication, which reports the replication ID and offset that PSYNC tracks. Some managed services disable PSYNC; it can often be enabled on request.
  • Scan mode uses the cursor-based SCAN iterator to walk the keyspace in batches without blocking the server. It works against locked-down managed instances where PSYNC is prohibited, at the cost of being snapshot-oriented rather than a continuous live tail.

Start the tool, point it from the old cluster to the new one, and let it stream until it's caught up.

3. Run the App in Redisson Multi Cluster Mode

The cleanest way to make the cutover atomic is Redisson PRO's Multi Cluster mode, which listens for a pub/sub signal to switch primaries. Configure it with two clusters - the old version first, the new version second:

multiClusterServersConfig:
  addresses:
    - "redis://redis-old.example.com:6379"   # cluster 1 - current version, primary at start
    - "redis://redis-new.example.com:6379"   # cluster 2 - new version, passive target
  datastoreMode: ACTIVE_PASSIVE
  primaryDiscoveryMode: FIRST_PRIMARY_PUBSUB_NOTIFICATION
registrationKey: "YOUR_REDISSON_PRO_LICENSE_KEY"

Each address identifies one whole cluster. FIRST_PRIMARY_PUBSUB_NOTIFICATION keeps the first cluster as primary and watches the control channel redisson:multicluster:primary for a message naming the new primary. Until that message arrives, your application reads and writes against the old cluster exactly as before - no code changes, because Redisson speaks the same protocol to both. RMap, RLock, RBucket, and the rest behave identically.

4. Switching

Once the replication tool reports it has caught up, connect to the current primary (the old cluster) and publish the new cluster's endpoint - as host:port, with no URL scheme - on the control channel:

redis-cli -c -h redis-old.example.com -p 6379 \
  PUBLISH redisson:multicluster:primary "redis-new.example.com:6379"

Every Redisson instance receives the notification and atomically switches its primary to the new cluster. From this moment, traffic flows to the upgraded version. Verify with INFO replication and your application metrics, then decommission the replication tool and - once you're confident - the old cluster. If anything looks wrong before you tear the old cluster down, publish its endpoint back on the same channel and you're instantly back where you started.

One last note: if the reason you're upgrading is the license change that landed with Redis 7.4, the same blue-green technique is exactly how you move to the BSD-licensed fork instead - see our companion guide on migrating a Redis Cluster to Valkey. Same machinery, different destination.