Cluster, Persistence & Stack — Series 2

Preview — 3 of 10 questions

How does an ASK redirection differ from a MOVED redirection in Redis Cluster?

javascript

-- Permanent: this slot now genuinely lives on a different node
MOVED 3999 10.0.0.5:6380

-- Temporary: this specific key is mid-migration to another node
-ASK 3999 10.0.0.5:6380
-- client must send:
ASKING
GET mykey    -- retried against the new node, without permanently rerouting slot 3999

AMOVED indicates a permanent reassignment — the client should update its slot-to-node mapping and route future requests for that slot directly to the new node; ASK indicates a temporary state during slot migration — the client should send the query to the indicated node but without updating its permanent routing table, since the slot isn't fully migrated yet, and must send an ASKING command immediately before the redirected query

BASK and MOVED are two names for the identical redirection mechanism, differing only in wording

CMOVED is used only for read commands, ASK only for write commands

DASK redirections are deprecated since Redis Cluster 6.0 and always resolved as MOVED now

What's the difference between a primary being subjectively down (SDOWN) and objectively down (ODOWN) in Redis Sentinel?

javascript

Sentinel-1: hasn't heard from primary in `down-after-milliseconds` → marks SDOWN locally
Sentinel-1: asks Sentinel-2 and Sentinel-3 "do you also see it as down?"
Sentinel-2: "yes, SDOWN here too"
Sentinel-3: "yes, SDOWN here too"
-- with quorum=2 reached (at least 2 Sentinels agree) → ODOWN declared
-- ONLY NOW does a failover attempt begin

ASDOWN is a permanent state requiring manual intervention; ODOWN automatically resolves itself after 60 seconds

BSDOWN means ONE Sentinel independently believes the primary is unreachable (based on its own health checks); ODOWN means enough OTHER Sentinels have also independently reported SDOWN to reach the configured quorum — only ODOWN actually triggers a failover attempt, preventing a single Sentinel's possibly-mistaken (e.g., due to its own network issue) view from unilaterally causing failover

CSDOWN and ODOWN are triggered in the opposite order — ODOWN must happen before SDOWN can be declared

DSDOWN only applies to replicas; ODOWN only applies to the primary

What do auto-aof-rewrite-percentage and auto-aof-rewrite-min-size control?

javascript

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Apercentage controls what fraction of write commands are logged to AOF at all; the rest are silently dropped for performance

BThese settings only apply when RDB persistence is completely disabled

CThey together determine when Redis automatically triggers a BGREWRITEAOF: once the AOF file has grown to at least min-size AND has grown by at least percentage% since the last rewrite (100% here means "doubled in size") — this keeps the AOF file from growing unboundedly while avoiding overly frequent rewrites on small files

Dmin-size sets a hard cap — Redis refuses to write to the AOF file once it exceeds this size

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