Skip to content
HotKVDocs

Ask the HotKV docs

Answers come only from these docs and can be wrong; check the linked pages before you rely on them.

High availability

Last updated

High availability means the data stays reachable when a node fails. In HotKV that comes from replicas plus a way to promote one of them. Which way depends on how you run HotKV:

Deployment Failover
Cluster mode with replicas Automatic: replicas elect a new primary without an operator
Standalone primary with replicas Manual: you promote a replica with REPLICAOF NO ONE (see Replication)
Standalone node without replicas None: recover from persistence
HotKV Cloud Single-node instances without replicas (see below)

No Sentinel

Section titled “No Sentinel”

HotKV has no Sentinel mode. There is no SENTINEL command, and a sentinel line in the configuration file stops the start with HotKV has no Sentinel mode. Clients that discover the primary through Sentinel cannot be pointed at HotKV that way.

For automatic failover, run cluster mode, even with a small number of primaries: every HotKV SDK and most Redis client libraries have a cluster client that follows failovers on their own. Outside cluster mode, failover is a manual promotion.

Automatic failover in cluster mode

Section titled “Automatic failover in cluster mode”

Give every primary at least one replica (for example redis-cli --cluster create ... --cluster-replicas 1). When a primary stops answering:

  1. The other nodes suspect it once it has not answered for cluster-node-timeout (default 15000 ms), and mark it as failing when a majority of the primaries that serve slots agree.
  2. Its most up-to-date replica asks the other primaries for votes and, with a majority, takes over its slots.
  3. The primary’s other replicas follow the new primary, and the old primary rejoins as a replica when it comes back.

Promotion takes roughly cluster-node-timeout plus a few seconds. Replicas and failover shows the timeline.

A replica whose data is too old (cluster-replica-validity-factor), that has not finished its first sync, or that has cluster-replica-no-failover yes does not start an automatic failover. Spare replicas move to cover a primary that has lost all of its own (cluster-migration-barrier, cluster-allow-replica-migration). The details are in Replicas and failover.

Elections need a majority of primaries. Run at least three primaries, on separate hosts or zones, so that losing one host never takes away the majority. A node cut off on the minority side of a network partition stops serving keys and replies CLUSTERDOWN instead of accepting writes that would be lost.

Manual failover

Section titled “Manual failover”

Run CLUSTER FAILOVER on a replica to make it the primary on purpose, for example before maintenance on the primary’s host:

10.0.0.4:6379> CLUSTER FAILOVER
OK

The plain form is coordinated: the primary pauses writes briefly while the replica catches up, so no acknowledged write is lost. FORCE skips that handshake for a primary that is unreachable, and TAKEOVER also skips the election, for when a majority of primaries cannot be reached. See Replicas and failover for when to use each, and for SHUTDOWN FAILOVER and shutdown-on-sigterm failover, which hand a primary’s slots to a replica when you stop it.

Outside cluster mode, promote a standalone replica with REPLICAOF NO ONE or REPLICATION.FAILOVER; see Replication. Redis’s FAILOVER command is not supported.

What clients see during a failover

Section titled “What clients see during a failover”
  • Redirects. Once the new primary owns the slots, requests that reach the old address get -MOVED slot host:port. Cluster clients refresh their slot map and retry on the new primary. Every HotKV SDK’s cluster client does this for you; see Connecting and SDKs.
  • A window of errors. Between the primary failing and the election finishing, its slots have no primary, and a client that talks to the dead node gets connection errors. About a node timeout after the failure, the other nodes mark the node as failed, and for a moment they answer -CLUSTERDOWN The cluster is down while cluster-require-full-coverage is yes (the default). With no, the other primaries keep serving their slots and only the failed primary’s keys are unreachable. cluster-allow-reads-when-down yes keeps reads working while the cluster is down. Clients should retry with a backoff.
  • During a coordinated CLUSTER FAILOVER, the primary holds writes to its slots for a moment, so clients wait and get no error.
  • Blocked clients. A client blocked on the old primary (for example in BLPOP) is sent -MOVED to the new primary when the old one is demoted, as Valkey does. Redis 7 closes such clients with -UNBLOCKED instead.
  • Writes in flight. Replication is asynchronous, so an automatic failover can lose writes the old primary acknowledged but had not yet sent to the replica that took over. A client that must not lose a write can call WAIT after it to wait until a replica has it.

HotKV Cloud

Section titled “HotKV Cloud”

HotKV Cloud instances are single nodes in one zone. The panel does not provision replicas or a second zone, so Cloud instances have no automatic failover. Your recovery options are the daily and manual backups on the Performance and Scale plans; see HotKV Cloud backups.

The Performance plan includes a 99.9% SLA and the Scale plan a 99.95% SLA.

Next steps

Section titled “Next steps”