Seite gesperrt

Diese Seite ist momentan von einem anderen Benutzer gesperrt. Warten Sie, bis dieser mit dem Bearbeiten fertig ist oder die Sperre abläuft.

Momentan gesperrt von: 216.73.217.120
Sperre läuft ab am: 2026/07/27 11:07 (14 min)

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.

====== ElasticSearch Sicherung und Crash Recovery ======

Gelegentlich kann es immer wieder passieren, dass hier die ElasticSearch nüchtern formuliert "crasht". Im Regelfall steht dann beim IndexServer der Status "disconnected". Die Gründe dafür können vielfältig sein:

  * die Indizesgröße ist zu groß für den Arbeitsspeicher (eher selten außer bei Kunden > 1000 Benutzer oder einer äquivalenten Menge an Dokumenten/Ordner im Index)
    * Abhilfe: hier wirds dann wirklich tricky. Clustering abweichend vom Standard ist möglicherweise notwendig.
  * zu viel Memory-Pressure vom VM-Host/Virtualisierungs-Host (bei Hyper-V bspw. Dynamic Memory, hier versuchen teilweise die Virtualisierer Speicher zu überbuchen oder zu sharen und diese Mechanismen sind teilweise eher bedingt durch den Einsatz von Windows sehr Microsoft-optimiert)
    * Abhilfe: den Virtualisierungsadministrator einmal bitten zu prüfen, ob hier Memory-Sharing passiert, ggf. Speicher an der VM anheben und exklusiv garantieren lassen. Kein einfaches Thema per se,
  * Hardware-Probleme (eher selten)
    * Defekter RAM (eher ganz selten)
    * Defekte I/O (HDD oder Controller)
  * Memory-Hogger: bspw. TeamViewer und Co. die sukzessive Speicher aufbauen können und in so lange nicht freigeben, solange die User-Session dauert etc.

Das Unangenehme bei ElasticSearch Crashes ist hier immer noch, dass der Hersteller keine Mechanismen zur konsistenten Snapshot Sicherung vorsieht (hier müsste per NEST oder Java API die Elastic angehalten werden, eine Sicherung an einen Backup Ort durchzuführen). Ein Rückgriff auf die gesicherten Dateien eines regulären Backups (bspw. Veeam etc.) ist in der Regel mit dem Risiko behaftet, dass hier "inkonsistente" Backups restort werden. Somit ist der primäre Weg, es sei denn man legt hier Programmierung für eine eigene Sicherungsroutine an, die Neuinstallation der ESearch Datenbasis mittels Serversetup.

===== Neuinstallation ESearch im Vergleich zu Leeren des Index Ordners =====

Als schnellste Lösung bei produktiven Systemen kann hier der Weg der Leerung des "ISearch-Data-Ordner" sein. Im Normalfall sollten sich hier 23/25er Systeme wieder von selbst regenerieren und auf der IndexServer/ISearch Statusseite kann ein "Re-Index" ausgelöst werden. Das geht hier binnen von wenigen Minuten ohne gröberes Update-Risiko.

Wählt man diesen Weg, dann sollte man im Hinterkopf behalten, dass hier kein "SearchGuard"-Modul installiert wird. Das ist hier jenes Modul, das hier per REST Statusabfragen zu Indices ermöglicht. Auf der Status-Seite von ELO wird dann im Regelfall nichts angezeigt.

Wenn genug Zeit bleibt sollte aber die ESearch neu installiert werden. Der Weg dorthin ist von Serversetup-Version zu Version dann unterschiedlich. Hier kann man den Weg versuchen:

  * den Applikationsserver zu deinstallieren per Setup.
  * danach nach Spuren nach dem alten Server im System suchen, diese backupen, verschieben oder ggf. auch löschen
  * ggf. den Dienst mit sc delete entfernen
  * danach neu installieren

===== Manuelle Installation des SearchGuard =====

Der SearchGuard kann hier auch manuell installiert werden. Hier sollte man den Output beim Serversetup beachten. Bei einer Neuinstallation kommt hier ein eigener Befehl zum Einsatz. Die ESearch muss hier zu diesem Zeitpunkt bereits laufen. Dies kann dann eine Neuinstallation über das Serversetup überflüßig machen.