Valkey and Dragonfly with Sentinel failover

Valkey with Sentinel

A highly available Valkey cluster is a primary, one or more replicas on separate servers and three Sentinels, which fit on three servers, or on two servers and a witness. Valkey 9.1 is the default, with 9.0 and 8.1 supported.

• Writes only reach a real primary: HAProxy sends rw traffic to a node only when it reports itself as primary and a majority of Sentinels agree, so two self-declared primaries never both take writes.
• No stale primary after a crash: a primary that restarts asks a Sentinel majority before taking its old role, and a forced start needs approval.
• A bounded loss window: replication is asynchronous, so a failover can lose the last writes; by default the primary stops accepting writes when no replica is within 10 seconds of it. The two-servers-and-a-witness layout drops that guard, and the plan says so.
• Failover target: at most 20 seconds from detection to the first successful write when the cluster has at least two replicas, with Sentinel’s detection set to five seconds by default.

Durable or cache

The durable profile, the default, keeps RDB persistence and never evicts keys. The cache profile has no persistence and evicts the least recently used keys. Memory is capped at 75% of the container’s limit to leave room for forks and buffers, and with persistence off a leftover snapshot is removed at start so old data never reappears.

Endpoints and clients

HAProxy exposes rw on port 6380 and ro on 6381, with an optional virtual IP; clients that understand Sentinel can use it directly on 26379. TLS is either required or off, and a custom certificate is terminated at HAProxy.

Backups

Snapshots are taken on a replica every six hours and kept for seven days by default, compressed and encrypted on the way to your repository. There is no point-in-time recovery for in-memory stores. Restores check the snapshot format, so a newer snapshot is never loaded into an older Valkey.

Day-2 operations and tools

• Switchover with Valkey 9’s coordinated failover; on 8.1, writes pause for at most four seconds.
• Rolling restarts with the Sentinels first, minor and major upgrades, adding and removing replicas.
• Configuration changes applied to every member, since Valkey doesn’t replicate them.
• ACL users with app, read-only and admin presets.
• A key browser and console that run on a replica and refuse dangerous commands such as FLUSHALL, KEYS and CONFIG SET, plus slow-log, latency and big-key insights.

Cluster mode with sharding across three or more shards is planned for v1.1.

Dragonfly

Dragonfly is a multi-threaded, Redis-compatible store suited to large single nodes. A single Dragonfly server is a supported topology. A primary with replicas, watched by three Valkey Sentinels, ships as beta until it passes the failover test matrix, because that pairing is not tested upstream.

• The endpoint layer and its checks are the same as Valkey’s: rw and ro through HAProxy.
• Dragonfly never starts itself as primary; recovery from a full outage needs approval. Switchover drains the primary and pauses clients for at most four seconds.
• Snapshots are taken on a replica every six hours, encrypted. Dragonfly’s own unencrypted snapshots to S3 are refused in production.
• A Valkey snapshot can be restored into Dragonfly, which is the migration path from Valkey.
• By default connections are encrypted and clients use passwords; in mutual-TLS mode every client presents a certificate from the cluster’s authority.

Dragonfly has no published failover target yet. If the release schedule gets tight, Dragonfly ships single-node only at first.