# High availability

> Automatic failover in HotKV cluster mode, manual failover, what clients see, Sentinel status, and HotKV Cloud availability.

URL: https://docs.hotkv.com/operate/high-availability/


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](https://docs.hotkv.com/clustering/index.md) 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](https://docs.hotkv.com/operate/replication/index.md#promoting-a-replica)) |
| Standalone node without replicas | None: recover from [persistence](https://docs.hotkv.com/persistence/index.md) |
| HotKV Cloud | Single-node instances without replicas (see [below](#hotkv-cloud)) |

## 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](https://docs.hotkv.com/clustering/index.md), 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

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](https://docs.hotkv.com/clustering/replicas-and-failover/index.md#automatic-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](https://docs.hotkv.com/clustering/replicas-and-failover/index.md).

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

Run [`CLUSTER FAILOVER`](https://docs.hotkv.com/commands/cluster-failover/index.md) 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](https://docs.hotkv.com/clustering/replicas-and-failover/index.md#start-a-failover-yourself) 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](https://docs.hotkv.com/operate/replication/index.md#promoting-a-replica). Redis's
`FAILOVER` command is not supported.

## 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](https://docs.hotkv.com/sdks/index.md).
- **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`](https://docs.hotkv.com/commands/wait/index.md) after it to wait until a replica has
  it.

> **Tip**
> Test your client's behaviour before you rely on it: in a staging cluster,
> run `CLUSTER FAILOVER` on a replica while your application is under load,
> and check it reconnects and retries without errors reaching users.

## 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](https://docs.hotkv.com/persistence/index.md#hotkv-cloud-backups).

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

## Next steps

- [Replicas and failover](https://docs.hotkv.com/clustering/replicas-and-failover/index.md)
- [Clustering](https://docs.hotkv.com/clustering/index.md)
- [Replication](https://docs.hotkv.com/operate/replication/index.md)
- [Troubleshooting](https://docs.hotkv.com/operate/troubleshooting/index.md)