Redis / Advanced: persistence, distribution and operations / Lesson 14

Replication, Sentinel and failover

Separate replica receipt, persistence and safe writer discovery. Explain Sentinel decisions and asynchronous loss windows without promising automatic zero-loss or globally exclusive business effects.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Explain asynchronous replication and Sentinel-aware discovery.
Distinguish acknowledgment reduction of risk from strong consistency.

A replica receives history under its own progress

Redis replication is asynchronous by default. A primary can acknowledge a write before every replica has processed it, so a newly promoted replica may not contain every recently acknowledged change. Reading a replica can also return older state than a primary read. Partial and full resynchronization have different costs and depend on retained replication history. Define which reads tolerate lag and how the application handles a lost writer before selecting replica count. More members do not automatically create a durable historical backup or eliminate correlated infrastructure failures.

Read replication evidence without changing topology

INFO replication is an inspection pattern for an existing authorized training connection. It can reveal role, link and progress information according to version and permissions. No live output is fabricated and no command is executed. One status sample is not proof that a particular business event exists on the replica or is durable on disk. Pair topology/progress evidence with application identity and the actual persistence contract. Managed services may expose equivalent metrics through a different interface or restrict this command, so follow their documented observation path rather than trying to bypass it.

redis Non-runnable replication inspection example

INFO replication

Expected shape is replication metadata, not a fixed healthy state. Field names and actual values require the deployed version’s documentation.

Sentinel coordinates discovery and promotion, not sharding

Sentinel monitors a primary/replica deployment and can coordinate failover and announce a new primary to compatible clients. Its quorum and failover-authorization requirements are distinct; changing a single detection number is not a universal availability recipe. Sentinel itself needs reachable, independently placed participants and appropriate authentication. A plain client pinned forever to an old primary address may continue failing or reach the wrong role after promotion. Sentinel does not distribute keys across shards and does not make every old writer’s external actions safely fenced. Application coordination must match the actual failure model.

Model acknowledged copies as a limited claim

The offline calculation counts which synthetic replicas have reached a write position. It does not implement WAIT, Sentinel or durable disk acknowledgment. Redis WAIT can reduce replication-loss risk by waiting for supported replica acknowledgments, but it does not turn asynchronous Redis into a strongly consistent consensus system or guarantee no acknowledged write can be lost at failover. Disk guarantees require additional versioned mechanisms and persistence assumptions. A count is useful only when its meaning, timeout and topology are understood, so keep the limited claim visible in the example and in operational reports.

python Offline replica-progress count

write_position = 20
replicas = {'replica-a': 20, 'replica-b': 18}
acknowledged = [name for name, position in replicas.items() if position >= write_position]
assert acknowledged == ['replica-a']
assert len(acknowledged) == 1

One modeled replica has reached position 20. The result proves no disk persistence, election safety or real Redis acknowledgment.

Define writer authority and outcome reconciliation

During a partition or failover, clients can face timeouts, role changes and uncertain writes. Preserve stable event identity and reconcile outcomes rather than retrying every increment blindly. A lock lease expiring or a new primary being elected does not prove an old process has stopped using an external resource; fencing belongs to a reviewed coordination protocol where required. Verify replication, persistence, client rediscovery and protected backups together through an authorized rehearsal. A restored connection is only one step toward service recovery, not proof of zero loss or exactly-once processing.

Common errors and fixes

A promoted replica lacks an acknowledged write

Why it happens: Asynchronous replication progress lagged the old primary.
How to fix it: Reconcile the business event and inspect the exact failure/persistence history.
Prevent it next time: Test acceptable loss under the actual topology and acknowledgment policy.

Clients keep using an obsolete writer endpoint

Why it happens: Discovery was not Sentinel-aware or refresh behavior failed.
How to fix it: Use the supported client discovery contract and verify role changes.
Prevent it next time: Include client rediscovery and TLS identity in failover rehearsal.

WAIT is advertised as strong consensus

Why it happens: Replica acknowledgment was confused with complete consistency and failover durability.
How to fix it: State the limited guarantee and review persistence/failure assumptions.
Prevent it next time: Keep risk reduction separate from zero-loss claims.

Check your understanding

1. Two replicas acknowledge a write. May a report claim it is impossible to lose that write?

Show worked solution

No. The claim depends on acknowledgment semantics, persistence, correlated failures and which node is promoted. WAIT reduces particular risks but does not establish universal strong consistency or zero-loss failover. Report the exact tested topology and guarantee, and keep independent recovery history and event reconciliation available.

2. Does Sentinel solve a hot-key distribution problem?