Elasticsearch / Editorial solution guide
Diagnose unassigned shards before recovery changes
Interpret health and allocation deciders while protecting the distinction between restored redundancy and accepted data loss.
Read-only knowledge base · No public comments
Recognize the symptoms
A versioned cluster becomes yellow or red after maintenance, storage pressure or a node failure. Searches may be partial, indexing can fail for affected primaries, or replica copies remain unassigned. Preserve index-level scope and the approved incident timeline; a cluster color alone cannot identify the missing data or its recoverability.
Understand the likely causes
- Allocation can be prevented by unavailable nodes, disk constraints, awareness requirements, filters or recovery failures. A lost primary and an unassigned replica are different conditions. The same visible color can arise from several causes, so a generic restart or reduced replica count can hide rather than repair the intended protection.
Identify the affected copy and service impact
Green means all required copies are allocated, yellow means all primaries but not every replica, and red means at least one primary is unassigned. Examine the relevant index rather than assuming every catalog index is equally affected. A yellow cluster may still serve data with reduced redundancy; a red index can have unavailable portions while other indices work. Preserve rejected-write and partial-search evidence so the application can reconcile what users actually experienced. This guide does not connect to the incident environment or collect operational identifiers.
Read an explanation for the exact shard
The diagnostic body targets a replica of a fictional catalog index. For a missing primary, primary would be true; choose the actual affected copy from approved evidence. Allocation deciders can explain why a candidate node is rejected. Compare those reasons with current disk, node roles, awareness and index allocation policy before proposing a narrow repair. A reason recorded at initial unassignment may differ from the constraint preventing allocation now, so use current explanation rather than an old screenshot alone.
{"index":"museum-artifacts-v1","shard":0,"primary":false}Read-only diagnostic body for POST /_cluster/allocation/explain with suitable authorization. No request is executed.
Do not trade away protection merely to change a color
Reducing replicas can make an index green without restoring the planned failure tolerance. Disabling disk safeguards can expose the cluster to a more severe storage failure. An approved response should name the violated constraint, the intended resilience objective and the evidence expected after repair. The local copy model below shows six copies for three primaries and one replica each; it does not establish placement or zone survival. Record any explicitly accepted temporary reduction in protection with a recovery owner and endpoint.
{"primary_shards":3,"replicas_per_primary":1,"required_copies":6,"scope":"copy arithmetic only"}The local calculation is 3 × (1 + 1) = 6. Actual allocation still depends on suitable nodes and constraints.
Separate safe-copy recovery from data-loss acceptance
If no valid current copy is available, follow the incident owner’s tested snapshot or authoritative-source recovery process. Forced stale-primary allocation can accept data loss and is not supplied as a tutorial remedy. Before any restoration, verify repository identity, snapshot scope, version compatibility and the handling of writes accepted after the recovery point. Replica copies do not protect against historical deletion, and filesystem data-directory copies are not a supported backup substitute. A green status after an unsafe operation cannot prove that the intended artifact history survived.
Verify the fix
Confirm allocation meets the approved redundancy and failure-domain design, then reconcile affected writes, document identities and partial search outcomes. Verify independent restore evidence where historical recovery was involved. No node restart, allocation mutation, replica change, snapshot or recovery operation was performed by this guide.
Keep it from recurring
- Keep capacity headroom, explicit allocation policies, tested maintenance sequencing and supported snapshot recovery. Monitor lost redundancy separately from application correctness, and assign clear ownership for restoring temporary protection reductions.