Cluster, Persistence & Stack — Series 3

Preview — 3 of 10 questions

A 3-master Redis Cluster needs a 4th master node added, with hash slots redistributed to include it. What's the operational mechanism for this?

AResharding is done via CLUSTER SETSLOT (moving individual slots' ownership, migrating their keys) — typically driven through redis-cli --cluster reshard, which handles the multi-step process of marking slots as migrating/importing on the source/destination nodes, moving the actual keys, and finally reassigning slot ownership, all while the cluster continues serving traffic for slots not currently being migrated

BAdding a node automatically triggers Redis to instantly and atomically rebalance every hash slot with zero manual intervention or configuration

CResharding requires taking the entire cluster offline, since hash slots cannot be reassigned while nodes are actively serving traffic

DNew nodes can only ever be added as replicas; new master nodes require creating an entirely new, separate cluster

Redis Sentinel doesnt fail over the primary the moment a single Sentinel process thinks its down. What role does quorum play?

Aquorum is the minimum number of Sentinel processes that must independently agree the primary is subjectively down (SDOWN) before it's promoted to the cluster-wide, agreed-upon objectively down (ODOWN) state that actually triggers a failover — a single Sentinel's own view (SDOWN, from the earlier Sentinel material) isn't trusted alone, specifically to avoid a failover triggered by one Sentinel's own network hiccup rather than a genuine primary outage

Bquorum is the minimum number of replica nodes required before a failover can even be attempted, unrelated to the Sentinel processes themselves

Cquorum sets the exact number of seconds Sentinel waits before declaring a primary down, with no relationship to how many Sentinels agree

Dquorum only matters for detecting replica failures, never primary failures

The appendfsync setting controls how often AOF writes are actually flushed to disk. What's the trade-off between always, everysec, and no?

AAll three settings provide identical durability guarantees; the setting only affects log verbosity

Bappendfsync only affects how AOF interacts with RDB snapshots, with no relationship to crash durability at all

Calways flushes to disk after every single write command — the strongest durability guarantee (essentially zero data loss window on a crash), at a real per-write performance cost. everysec (the default, and the usual recommended middle ground) flushes about once per second, risking up to roughly a second of recent writes on a crash, but at dramatically better throughput than always. no lets the operating system decide when to flush entirely, which can mean a much larger, unpredictable data-loss window on a crash, in exchange for the least per-write overhead

Dalways and everysec are functionally identical; only no differs meaningfully

Answer all 10 questions (7 more), see explanations for every answer, and track your score.