Replication, Sentinel and high availability

Setting up replicas, measuring replication lag, Sentinel quorum and failover, persistence trade-offs and an executable upgrade plan.

Replication

# on the primary
bind 10.0.0.10
requirepass ...          # or an ACL user
masterauth ...

# on each replica
replicaof 10.0.0.10 6379
replica-read-only yes
replica-serve-stale-data yes
repl-backlog-size 64mb
min-replicas-to-write 1
min-replicas-max-lag 10

redis-cli INFO replication
# role:master
# connected_slaves:2
# slave0:ip=10.0.0.11,state=online,offset=12345,lag=0

redis-cli -h 10.0.0.11 INFO replication | grep master_repl_offset

# WAIT reports how many replicas acknowledged a write
redis-cli SET important value
redis-cli WAIT 1 100        # at least 1 replica, within 100 ms

Replication is asynchronous. A client that writes and immediately reads from a replica can see the old value; a failover can lose the last writes.
min-replicas-to-write plus min-replicas-max-lag makes the primary refuse writes when it is effectively isolated from all replicas - a safety valve against a partitioned primary that keeps accepting writes.
WAIT gives a per-write acknowledgement barrier without making replication synchronous forever, which is usually the right compromise.
A replica that goes offline and returns resynchronises incrementally from the backlog if the offset is still available, otherwise it does a full sync that copies the whole dataset.

⚠️

A replica is a copy, not a backup. If someone runs FLUSHALL on the primary it replicates instantly. Keep separate RDB or AOF backups, stored off the instance, and verify that a restore works.

Sentinel and failover

# sentinel.conf, one file per Sentinel process, three or more across hosts
port 26379
sentinel monitor mymaster 10.0.0.10 6379 2
sentinel auth-pass mymaster ...
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
redis-cli -p 26379 SENTINEL failover mymaster    # manual, for testing
redis-cli -p 26379 SENTINEL ckquorum mymaster

Setting	Meaning	Risk if wrong
`quorum`	Sentinels that must agree the primary is down	Too low means a false failover; too high means no failover
`down-after-milliseconds`	Time before a subjective down vote	Too low causes failovers on a brief network hiccup
`failover-timeout`	Bounds retries of the failover itself	Too low causes repeated elections
`parallel-syncs`	Replicas resyncing at once	Too many means a burst of full syncs and load

Clients must ask Sentinel for the current primary rather than caching an address. Every mature client library has a Sentinel mode - use it, and make the client reconnect and rediscover after a failover error.

Persistence and upgrades

# RDB: point-in-time snapshots, small files, fast restarts
save 900 1
save 300 10
save 60 10000
rdbcompression yes
dbfilename dump.rdb

# AOF: better durability, larger files, slower restart
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-use-rdb-preamble yes

Configuration	Data at risk on crash	Cost
`appendfsync no`	Up to 30 seconds	Fastest writes
`appendfsync everysec`	Up to 1 second	The usual balance
`appendfsync always`	Effectively none	An fsync per write - often ten times slower
RDB only	Since the last snapshot	Fast restarts and smaller files

Test the actual restore path, not just the backup. Start a server against a copy of the AOF and confirm the key count matches.
Keep the RDB and AOF files off the instance. A disk failure takes the server and its backups together.
During an upgrade, fail over to a replica running the new version, verify, then upgrade the old primary - or accept a short window of read-only service.
A failed background save leaves the previous dump in place, so the data is safe but the backup is stale; alert on rdb_last_bgsave_status rather than assuming it works.

FAQ

Sentinel or Redis Cluster?

Sentinel when your dataset fits in one instance and you need failover for a single primary with replicas. Cluster when you need to shard the dataset or write throughput beyond one node - and accept the multi-key restrictions it imposes.

How much write loss is acceptable on failover?

That is a product decision, not a technical one. With asynchronous replication a failover can lose the last writes, so anything that must not be lost needs WAIT, min-replicas-to-write, or to live in the primary transactional database instead.

Clustering and client libraries in applications Security: ACLs, TLS and hardening

Last refreshed 2026-09-18.

Replication, Sentinel and high availability

Replication

Sentinel and failover

Persistence and upgrades

FAQ

Related