Elasticsearch-Rolling-Upgrade (8.x Minor oder 8.19 → 9.x)

Keine Installation: Ein laufender Elasticsearch-Cluster wird ohne Ausfallzeit auf eine neue Version gebracht, indem die Nodes einzeln aktualisiert werden (Minor-Upgrade innerhalb von 8.x oder Major-Upgrade 8.19 → 9.x). Schritt für Schritt: Vorabprüfungen (Version, Zustand, Deprecation API, System Feature Migration), Snapshot vor dem Upgrade, Shard Allocation auf Primaries begrenzen und Flush, Versions-Update und Plugins je Node, Allocation wieder freigeben und auf den Zustand warten, Kibana-Upgrade und bei Bedarf Rückkehr aus dem Snapshot. Am Ende laufen alle Nodes und Kibana auf der Zielversion, der Cluster ist green. Willst du von einer 8.x älter als 8.19 auf 9.x wechseln, wende diesen Guide zuerst mit der Option „Innerhalb derselben Hauptversion“ an, um 8.19 zu erreichen; gibt es kein Snapshot-Repository, öffne zuerst den Snapshot-Guide.

Topologie: Bestehender Cluster mit 3+ Nodes (+ Kibana)

Szenarien

• Innerhalb derselben Hauptversion (z. B. 8.18 → 8.19, 9.1 → 9.2) — Innerhalb derselben Hauptversion (8.18 → 8.19, 9.1 → 9.2): Das Repository bleibt gleich, die Deprecation-Prüfung wird trotzdem durchgeführt. Das Überspringen von Minor-Zwischenversionen wird unterstützt.
• Hauptversion: 8.19.x → 9.x — Der Quell-Cluster muss vorher auf 8.19.x (letzter Patch) aktualisiert sein. Die Vorabprüfungen umfassen Upgrade Assistant / Deprecation API und die System Feature Migration.

Vor dem Start

• Alle Nodes laufen auf derselben Version: …. …Für den Wechsel auf 9.x muss die Quellversion 8.19.x sein (außer 8.18 → 9.0); andernfalls wende diesen Guide zuerst mit der Option „Innerhalb derselben Hauptversion“ an und wechsle auf 8.19.…Die Zielversion … muss neuer sein als die aktuelle Version; das Überspringen von Minor-Zwischenversionen (8.17 → 8.19) wird unterstützt.…
• Cluster ist green; keine relocating/initializing Shards; Plattenbelegung auf allen Nodes unter 75 % (während des Upgrades werden Shards neu aufgebaut).
• Anwendungsclients, Logstash, Beats/Elastic Agent und APM sind mit der Zielversion kompatibel. …Für 9.x werden die Client-Bibliotheken in Version 9.x (oder 8.x mit Kompatibilitäts-Headern) benötigt; lies die Breaking Changes in den Release Notes.…
• Snapshot-Repository … ist registriert und verifiziert und hat genug freien Platz für den Snapshot. Ein aktualisierter Node lässt sich nicht auf die alte Version zurücksetzen; dieser Snapshot ist der einzige Weg zurück.
• Die Server erreichen artifacts.elastic.co (oder einen internen Mirror), und … ist im Repository vorhanden.
• Das Wartungsfenster ist genehmigt; die Schreiblast ist während des Upgrades nach Möglichkeit reduziert (nicht zwingend). …Alle kritischen Warnungen in Kibana unter Stack Management → Upgrade Assistant sind behoben.…

Phasen der Anleitung

• Vorbereitung — Temporäre Zugangsdatendatei für den API-Zugriff anlegen · Konfiguration sichern · Installierte Plugins auflisten
• Vorabprüfungen — Versionen und Rollen prüfen · Cluster-Zustand prüfen · Deprecation-Prüfung durchführen (Upgrade Assistant API) · System Feature Migration ausführen · Installierbare Zielversionen auflisten
• Repository auf 9.x umstellen — Elastic-9.x-Repository einrichten · Elastic-9.x-Repository einrichten · Zielversion prüfen
• Rückkehrpunkt: Snapshot — Snapshot vor dem Upgrade erstellen · ML Upgrade Mode aktivieren
• Verifizierung — Prüfen, ob alle Nodes auf der Zielversion laufen · Prüfen, ob die Allocation-Einstellung dauerhaft entfernt ist · ML Upgrade Mode deaktivieren · Logs auf Fehler prüfen
• Kibana aktualisieren — Kibana stoppen · Kibana auf … aktualisieren · Kibana starten und Status prüfen
• Nach der Installation — Snapshot nach dem Upgrade erstellen · Temporäre Zugangsdatendatei löschen
• Rückkehr (nur wenn das Upgrade fehlschlägt) — Dienst auf allen Nodes stoppen · Alte Version installieren · Datenverzeichnis beiseitelegen und ein leeres anlegen · Einstellung initial_master_nodes für den neuen Cluster schreiben · Dienste starten · Temporäres elastic-Passwort festlegen …