A Redis Cluster starts rejecting commands with CLUSTERDOWN and CLUSTER INFO reports cluster_state:fail. Explain what hash-slot coverage means, how you identify which slots have no owner, and what the cluster-require-full-coverage setting changes.

## What coverage means Redis Cluster partitions the keyspace into 16384 slots. The cluster is *fully covered* when every slot number 0..16383 is claimed by exactly one master that is reachable and considered healthy by the majority. Coverage is a property of the slot-to-node map, not of the data: a slot can be covered and empty, or uncovered while its data still exists on a node that the cluster considers failed. There are three ways coverage breaks: 1. **A master fails with no replica available to promote.** Its slots become unowned from the cluster's point of view. 2. **An aborted or half-finished resharding.** Slots left in `importing`/`migrating` state, or explicitly unassigned by a failed operation, leave holes. 3. **Administrative accidents** - `CLUSTER RESET` on a live node, a node re-added with an empty config, deleting a node that still owned slots. ## Reading the state `CLUSTER INFO` is the fastest probe: - `cluster_state:ok|fail` - the node's verdict on whether the cluster can serve. - `cluster_slots_assigned` - how many of the 16384 have any owner at all. Below 16384 means holes. - `cluster_slots_ok` - assigned slots whose owner is believed healthy. - `cluster_slots_pfail` / `cluster_slots_fail` - slots whose owner is suspected (pfail) or agreed (fail) to be down. - `cluster_known_nodes` and `cluster_size` (masters serving at least one slot) help spot a node that vanished. `CLUSTER NODES` shows the per-node detail: flags including `fail?`/`fail`, and the slot ranges each node claims. Summing the claimed ranges of healthy masters tells you exactly which numbers are missing. `redis-cli --cluster check <host:port>` does this arithmetic for you, printing coverage and flagging slots that are unassigned or claimed by more than one node; `--cluster fix` will attempt to close the holes and finish stuck migrations. Always ask more than one node. Each node reports its own gossiped belief, so during a partition the minority side may declare `fail` while the majority side is happily serving. ## What cluster-require-full-coverage does The default is `yes`, and it is a deliberately conservative availability stance: **if any slot is uncovered, every master refuses every command** with `CLUSTERDOWN The cluster is down` - including commands for slots that are perfectly healthy. The rationale is correctness in the common case where Redis backs a system that assumes the whole keyspace is present: an application that silently gets "key not found" for a shard's worth of data may take wrong actions (re-registering users, re-charging, recomputing and caching wrong values), whereas an explicit error usually triggers a clean fallback or a page. Setting `cluster-require-full-coverage no` flips the trade: each master continues to serve the slots it owns, and only keys hashing into uncovered slots fail (with `CLUSTERDOWN Hash slot not served`). That is the right choice when Redis is a pure cache whose misses are cheap and safe - losing 1/3 of a cache is far better than losing 100% of it. It is the wrong choice when Redis holds authoritative state, or when a partial view can produce silent data corruption downstream. The setting is applied per node, so change it everywhere; it can be set live with `CONFIG SET cluster-require-full-coverage no` and must also be persisted in the config file to survive a restart. A related knob is `cluster-allow-reads-when-down`, which permits reads even while the node considers the cluster down, again trading consistency for availability. ## The response, in order 1. Confirm scope: `CLUSTER INFO` on several nodes; is it a genuine hole or one node's minority view? 2. Identify the missing ranges: `CLUSTER NODES` / `redis-cli --cluster check`. 3. Find the cause. Down master with no replica? Promote or restart the node so its slots return. Stuck migration? Finish or roll it back with `--cluster fix` (or `CLUSTER SETSLOT ... NODE`) rather than hand-assigning slots blindly. 4. Only assign orphaned slots to a fresh node once you accept that the data in them is gone - `CLUSTER ADDSLOTS` on an empty node restores availability at the cost of that slice of data. 5. Afterwards, fix the structural cause: every master should have at least one replica, `cluster-migration-barrier` should allow spare replicas to move to a master that lost its own, and alerting should watch `cluster_state` and `cluster_slots_ok` directly rather than only client error rates. ## Nuance worth stating Coverage is about ownership, not about node count: a single master can legally own all 16384 slots, and a cluster with dozens of nodes is still `fail` if one range is unclaimed. Conversely, `cluster_state:ok` says nothing about whether every master has a replica - a fully covered cluster with no redundancy is one crash away from being uncovered.