Probleme mit der Elasticsearch-Shard-Zuweisung: Ursachen und Lösungen

Probleme mit der Elasticsearch-Shard-Zuweisung zeigen sich normalerweise als gelbe oder rote Cluster-Gesundheit. Gelb bedeutet, dass Ihre primären Shards zugewiesen sind, aber mindestens ein Replikat nicht. Rot bedeutet, dass mindestens ein primärer Shard nicht zugewiesen ist, sodass einige Daten möglicherweise nicht verfügbar sind, bis Sie sie wiederherstellen.

Diese Anleitung zeigt Ihnen, wie Sie den Zuweisungsblocker finden, die Ausgabe der Allocation-Explain-API lesen und die risikoärmste Lösung auswählen. Das Ziel ist es, die Zuweisung wiederherzustellen, ohne den Datenverlust zu verschlimmern.

Grundlegendes zu Shard-Zuständen und Cluster-Gesundheit

Shards sind die Einheit, die Elasticsearch auf Datenknoten platziert. Sie können in verschiedenen Zuständen existieren:

• STARTED: Der Shard ist aktiv und bedient Anfragen.
• RELOCATING: Der Shard bewegt sich von einem Knoten zu einem anderen.
• INITIALIZING: Der Shard wird erstellt oder wiederhergestellt.
• UNASSIGNED: Der Shard existiert in den Cluster-Metadaten, ist aber keinem Knoten zugewiesen.

Die Cluster-Gesundheit folgt diesen Shard-Zuständen:

• Grün: Alle primären und Replikat-Shards sind zugewiesen.
• Gelb: Alle primären Shards sind zugewiesen, aber ein oder mehrere Replikate sind nicht zugewiesen.
• Rot: Ein oder mehrere primäre Shards sind nicht zugewiesen. Suchanfragen können für betroffene Indizes teilweise Ergebnisse zurückgeben oder fehlschlagen, und Schreibvorgänge in diese Indizes können fehlschlagen.

Häufige Ursachen für Fehler bei der Shard-Zuweisung

Elasticsearch verwendet Zuweisungsentscheider, bevor ein Shard platziert wird. Eine einzige NO-Entscheidung kann einen Shard nicht zugewiesen lassen.

Festplatten-Wassermarken

Festplattendruck ist eine der häufigsten Ursachen. Elasticsearch verwendet Festplatten-Wassermarken, um zu vermeiden, dass ein Knoten voll wird. Sobald ein Knoten die niedrige oder hohe Wassermarke überschreitet, werden Zuweisungsentscheidungen restriktiver. Bei der Flutstufen-Wassermarke kann Elasticsearch einen schreibgeschützten Block für betroffene Indizes hinzufügen, um den Knoten davor zu schützen, dass der Festplattenspeicher ausgeht.

Einstellung	Häufiger Standardwert	Effekt
cluster.routing.allocation.disk.watermark.low	85%	Vermeidet die Zuweisung zusätzlicher Shards zu Knoten über diesem Schwellenwert.
cluster.routing.allocation.disk.watermark.high	90%	Versucht, Shards wegzubewegen und vermeidet die Platzierung von Shards auf dem Knoten.
cluster.routing.allocation.disk.watermark.flood_stage	95%	Kann Schreibvorgänge auf betroffenen Indizes blockieren.

Bestätigen Sie die tatsächlichen Einstellungen Ihres Clusters, bevor Sie etwas ändern:

GET /_cluster/settings?include_defaults=true&filter_path=**.disk.watermark*

Überprüfen Sie dann die Festplattennutzung des Knotens:

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total,shards

Geben Sie Speicherplatz frei, fügen Sie eine Festplatte hinzu, fügen Sie Datenknoten hinzu, löschen Sie alte Indizes oder reduzieren Sie den Replikatdruck. Wenn ein Flutstufen-Block gesetzt wurde, entfernen Sie ihn erst, nachdem der Festplattendruck behoben ist:

PUT /my_index/_settings
{
  "index.blocks.read_only_allow_delete": null
}

Knotenrollen und Zuweisungsfilter

Index-Shards werden nur Knoten mit einer Datenrolle und passenden Zuweisungsfiltern zugewiesen. Wenn Sie Knotenattribute für Hot/Warm-Tiers, Racks, Zonen oder Speichertypen verwenden, kann ein Tippfehler Shards stranden lassen.

Beispielsweise wird ein Index mit index.routing.allocation.require.box_type: high_io nur auf Knoten zugewiesen, die mit node.attr.box_type: high_io konfiguriert sind.

Überprüfen Sie Indexfilter und Knotenattribute:

GET /my_index/_settings?filter_path=*.settings.index.routing.allocation
GET /_cat/nodeattrs?v
GET /_cat/nodes?v&h=name,roles,disk.used_percent

Korrigieren Sie die Indexeinstellung oder fügen Sie einen geeigneten Datenknoten hinzu. Entfernen Sie die Zuweisungs-Awareness nicht leichtfertig in Multi-Zonen-Clustern; dies könnte alle Kopien eines Shards in derselben Fehlerdomäne platzieren.

Fehlende primäre Shards

Wenn ein primärer Shard nicht zugewiesen ist, kann der Knoten, der den aktiven Primär-Shard gehalten hat, weg sein, der Index wurde möglicherweise gerade wiederhergestellt, oder Zuweisungsregeln blockieren möglicherweise jeden geeigneten Knoten. Gehen Sie nicht davon aus, dass Daten verloren sind, bis die Allocation-Explain-API Ihnen sagt, warum Elasticsearch den Shard nicht zuweisen kann.

Häufige Szenarien sind:

• Ein Knoten, der die einzige gute Primärkopie hielt, ist abgestürzt.
• Zuweisungsfilter schließen jeden Datenknoten aus, der den Primär-Shard hosten könnte.
• Eine Snapshot-Wiederherstellung oder Indexerstellung wartet auf geeignete Knoten.
• Es existiert eine veraltete Shard-Kopie, aber Elasticsearch wird sie ohne explizite Akzeptanz von Datenverlust nicht hochstufen.

Versuchen Sie zuerst, den fehlenden Knoten wiederherzustellen, einen Snapshot wiederherzustellen oder den Zuweisungsblocker zu beheben. Verwenden Sie die erzwungene Primärzuweisung nur, wenn Sie verstehen, welche Kopie veraltet ist, oder wenn Sie den Datenverlust für diesen Shard akzeptiert haben.

Shard-Limits

Shard-pro-Knoten-Limits können die Zuweisung ebenfalls blockieren. Häufige Einstellungen sind index.routing.allocation.total_shards_per_node und cluster.routing.allocation.total_shards_per_node.

Überprüfen Sie auf diese Limits:

GET /_cluster/settings?include_defaults=true&filter_path=**.total_shards_per_node
GET /my_index/_settings?filter_path=*.settings.index.routing.allocation.total_shards_per_node

Fügen Sie Knoten hinzu, reduzieren Sie die Replikatanzahl, konsolidieren Sie kleine Indizes oder erhöhen Sie vorsichtig das relevante Limit. Zu viele Shards pro Knoten können den Heap-Druck erhöhen und Cluster-Zustandsoperationen verlangsamen.

Diagnose mit der Allocation-Explain-API

Die Allocation-Explain-API ist das beste Werkzeug, um die Frage zu beantworten: "Warum wird dieser Shard nicht zugewiesen?"

GET /_cluster/allocation/explain?pretty
{
  "index": "my_data",
  "shard": 0,
  "primary": true
}

Um Elasticsearch einen derzeit nicht zugewiesenen Shard auswählen zu lassen, rufen Sie die API ohne Body auf:

GET /_cluster/allocation/explain?pretty

Lesen Sie zuerst diese Felder:

• can_allocate: Die Antwort auf hoher Ebene.
• allocate_explanation: Die Zusammenfassung in einfachem Englisch.
• node_allocation_decisions: Entscheidungen pro Knoten.
• deciders: Die genaue Regel, die NO oder THROTTLE zurückgegeben hat.

Eine NO-Entscheidung ist der Blocker. Eine THROTTLE-Entscheidung bedeutet normalerweise, dass Elasticsearch den Shard zuweisen kann, aber die gleichzeitige Wiederherstellungsarbeit einschränkt.

Sichere Fehlerbehebungssequenz

Beginnen Sie breit, dann grenzen Sie ein.

1. Überprüfen Sie die Cluster-Gesundheit und nicht zugewiesene Shards

GET /_cluster/health?pretty
GET /_cat/shards?v&h=index,shard,prirep,state,unassigned.reason,node

Schauen Sie sich unassigned.reason an. Werte wie NODE_LEFT, INDEX_CREATED, CLUSTER_RECOVERED oder ALLOCATION_FAILED sagen Ihnen, wo Sie als nächstes suchen müssen.

2. Überprüfen Sie die Festplatten- und Knotenberechtigung

GET /_cat/allocation?v&h=node,disk.used_percent,disk.avail,disk.total
GET /_cat/nodes?v&h=name,roles,heap.percent,ram.percent,cpu,disk.used_percent

Wenn Knoten nahe der hohen Wassermarke sind, beheben Sie den Festplattendruck, bevor Sie die Zuweisungseinstellungen ändern.

3. Führen Sie Allocation Explain aus

Verwenden Sie den betroffenen Index, die Shard-Nummer und das Primär-/Replikat-Flag. Die Ausgabe sollte die Einstellung, den Knotenzustand oder den Entscheider nennen, der die Zuweisung blockiert.

4. Vermeiden Sie riskante Umleitungen, bis Sie die Ursache kennen

Manuelle Umleitungsbefehle sind für spezifische Wiederherstellungsfälle gedacht. Sie sind keine allgemeine Lösung für Festplattendruck, schlechte Filter oder zu viele Replikate.

Wenn eine veraltete Primärkopie der einzig praktikable Wiederherstellungspfad ist, sieht der Befehl so aus:

POST /_cluster/reroute
{
  "commands": [
    {
      "allocate_stale_primary": {
        "index": "index_name",
        "shard": 0,
        "node": "node_name_with_stale_copy",
        "accept_data_loss": true
      }
    }
  ]
}

accept_data_loss: true wird aus gutem Grund benötigt. Verwenden Sie es nur, nachdem Sie Snapshots überprüft, versucht haben, den fehlenden Knoten wiederherzustellen, und bestätigt haben, welcher Knoten die veraltete Kopie enthält.

5. Behandeln Sie gelbe Gesundheit separat

Wenn nur Replikate nicht zugewiesen sind, kann der Cluster weiterhin Primärdaten bedienen. Beheben Sie zuerst die zugrunde liegende Ressourcenbeschränkung. Das Hinzufügen eines Datenknotens, das Freimachen der Festplatte oder das Korrigieren von Zuweisungsfiltern ermöglicht Elasticsearch in der Regel, Replikate automatisch zuzuweisen.

Wenn Sie vorübergehend ohne Replikate auskommen müssen, reduzieren Sie die Replikatanzahl für den betroffenen Index:

PUT /my_index/_settings
{
  "index.number_of_replicas": 0
}

Dies kann die Gesundheit grün werden lassen, da Elasticsearch keine Replikatkopien mehr für diesen Index erwartet. Es reduziert auch die Verfügbarkeit, setzen Sie die Replikate also auf den gewünschten Wert zurück, nachdem Sie Kapazität hinzugefügt oder die Zuweisung behoben haben.

Vermeidung von Zuweisungsproblemen

• Alarmieren Sie, bevor Knoten die hohe Festplatten-Wassermarke überschreiten.
• Halten Sie genügend Datenknoten für Ihre Replikatanzahl und Zuweisungs-Awareness-Regeln bereit.
• Verwenden Sie Shard-Anzahlen, die zu Ihrem Heap, Datenvolumen und Wiederherstellungszielen passen.
• Überprüfen Sie Indexvorlagen, damit neue Indizes keine schlechten Replikatanzahlen oder Zuweisungsfilter erben.
• Testen Sie Knotenersatz- und Snapshot-Wiederherstellungsschritte vor einem Vorfall.

Fazit

Ihr sicherster Weg ist einfach: Identifizieren Sie den nicht zugewiesenen Shard, führen Sie Allocation Explain aus, beheben Sie den Entscheider, der NO sagt, und vermeiden Sie erzwungene Zuweisungen, es sei denn, Sie haben den Datenverlust-Kompromiss akzeptiert.