Incident Library
Applied filters Root causeOperator errorComponentElasticsearch or OpenSearchSymptomData lossClear allEvery case under the filters, with no sentence; newest first.
Suggested filters Search, and the values found in your words appear here.

Graph

  • Root cause
  • Component
  • Symptom
  • Contributing factor
  • Case

Cases1 case

1 to 1 of 1

  1. Symptoms

    After an OpenStack host server went down and took one Elasticsearch node with it, the health check that the API servers run against Elasticsearch returned false, although the Head plugin showed the cluster status as green. The check stayed false after the node was brought back and the cluster was green again.

    Trigger

    An OpenStack host server went down, and one node of the Elasticsearch cluster went down with it.

    Root cause
    Component
    Contributing factor
    Detection

    The health check that the API servers run against Elasticsearch returned false while the Head plugin showed the cluster as green.

    Remediation
    • Migrated the Elasticsearch node's virtual server to another host after the failed host recovered
    • Started the node's Elasticsearch process and let it rejoin the cluster
    • Restarted all nodes in order from node 1, pausing at about the twentieth when the API slowed
    • Restarted all nodes again from node 1, which ended the API delays but left 12 shards unassigned
    • Tried to move an unassigned shard with the allocate command of _cluster/reroute, which failed
    • For index A, copied node 22's shard files to nodes 3 and 10 and set primary to true in node 22's state file
    • For index B, deleted the broken shard files on node 27, copied node 28's files to node 27 and other nodes and marked node 28 primary
    • For index C, copied shards 2 and 4 from nodes 27 and 25 to two other nodes each and marked the copies as not primary
    Action items
    • Upgrade Elasticsearch and stop running such an old version
    Lessons

    Automatic shard reallocation should have been turned off before restarting nodes. After each node restart, the next node should have been restarted only after reallocation had completely finished, not just after the log file looked fine.

Check your cluster for this

This case involves Elasticsearch or OpenSearch. kubegap audits a Kubernetes cluster for gaps like these, read-only, from Claude Code or Codex; its checks cite public reports like the ones in this library.

By root cause1