A network partition leaves a Redis master reachable by some application clients but cut off from all Redis Sentinel processes, so Sentinel promotes a replica on the other side. What happens to the writes those clients keep sending to the old master, what actually bounds how long that can go on, and which Sentinel-side settings or hooks (down-after-milliseconds, client-reconfig-script, replica-priority) let an operator observe or shorten that window?

## The shape of the problem Redis Sentinel is a set of *separate* processes that watch a master, agree it is unreachable, and promote one of its replicas. That separateness is the whole of this question. The shard itself — the master and its replicas — has no vote in the decision and no self-awareness about role changes. A Redis master does not track whether it can still reach a quorum of anything; it serves whoever connects to it. So when a partition puts the master on the minority side, two things happen at once. On the majority side, Sentinels reach agreement (subjectively down → objectively down → leader election) and promote a replica; that side now has a legitimate master. On the minority side the old master is *untouched*. Nobody has told it anything, because the only channel by which Sentinel could is the one the partition broke. It still answers `INFO` with `role:master`, still accepts `SET`, still returns `+OK`. ## Split brain, and who ends it Every client that shares the minority side with the old master keeps writing successfully. Those writes are doomed, but at the time they are indistinguishable from real ones — the client got a success reply. The critical operational fact: **nothing on the server ends this window.** In a design where the data nodes themselves run the agreement, the node can fence itself. Redis Cluster is the in-family example: a primary that cannot reach a majority of masters for `cluster-node-timeout` enters an error state and stops serving its slots. The loss window there is bounded by a server-side timer you configure. Sentinel-managed Redis has no equivalent. The window ends only when the *clients* stop talking to the old master, so it is bounded by: - **`+switch-master` propagation** — Sentinel publishes this event on its own pub/sub channel. Only Sentinel-aware clients connected to a reachable Sentinel learn from it, and clients stranded on the minority side may reach no Sentinel at all. - **Connection teardown** — an idle TCP connection to a still-alive host is not broken by a partition elsewhere in the network. A pooled connection to the old master can stay usable indefinitely. - **Indirection lag** — if clients find the master through DNS, a VIP, or a proxy, the window is that layer's TTL, health-check interval, or script latency. - **Client configuration** — a client with a hardcoded master `host:port` never re-resolves at all. Its window is unbounded. Which is why the honest answer to "how much can we lose?" is a *client-fleet* number, not a server setting. ## Why the writes vanish silently When the partition heals, the Sentinel leader sends `REPLICAOF <new-master>` to the old master. It becomes a replica, and because its replication history has diverged from the promoted node's, a partial resync is impossible — it performs a **full resync**, loads the new master's RDB, and *replaces its own dataset*. The divergent writes are not merged, not logged, not surfaced. Clients that got `+OK` were told the truth about local state and a lie about durable state, and no artifact of the discrepancy survives anywhere. ## What the operator can observe and configure - **`down-after-milliseconds`** (per monitored master in sentinel.conf) is how long a master must be unresponsive before a Sentinel marks it subjectively down. Lowering it shortens time-to-promotion — but it does **not** shorten the minority-side write window, and can widen the overlap: promoting sooner while clients still write to the old node means more divergent data. Detection latency and client-failover latency are two different clocks; the loss window is the gap between them. - **Sentinel-aware clients** subscribed to `+switch-master` that drop pooled connections and re-resolve are the primary lever. Measure it as a real number: failover event → first successful write against the new master, per client fleet. - **`client-reconfig-script`** runs on the Sentinel leader during failover with the old and new master addresses. Use it to move a VIP, reload a proxy backend, or update service discovery, so clients that do not speak Sentinel are cut over instead of being left pointing at a live-but-orphaned node. - **`replica-priority`** on each replica steers *which* node gets promoted (`0` = never promotable). It does not bound the window, but it keeps a deliberately-lagging or cross-region replica out of the running, which is part of the same failover-quality budget. - **Server-side write fencing** — making the isolated master refuse writes when too few replicas are keeping up — is the one true server-side fence available with Sentinel, and it is covered under `cluster-failover-min-replicas-to-write`. - **Observability**: alert on the Sentinel channel's `+sdown`, `+odown`, `+switch-master`, and on any period where two nodes of one shard both report `role:master`. That last signal is invisible from a single node's metrics — you have to compare across the shard. ## The judgment Sentinel buys automatic failover, not a consensus-backed shard. The divergent-write window is a property of your client fleet and your indirection layer, not of Redis; budget for it explicitly, drive it down with Sentinel-aware clients plus `client-reconfig-script`, and keep data that cannot survive it out of a Sentinel-managed Redis.