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.

Ein durchaus möglicher Weg, der hier mit Version 23 LTS getestet werden konnte (Ende 2025 Serversetup) ist hier folgender Weg:

• Beenden der Dienste
  • Danach die MMC mit der Dienstliste schließen auch den TaskManager um die Service-Handles freizugeben
• Löschen des Dienstes (mit der Endung -iSearch, sc delete <ServiceName>)
• Umbennenen / Löschen des ISearch Datenordners
• Umbennenen / Löschen des ISearch Konfigurationsordners
• Kontrolle ob der Dienst gelöscht ist, ggf. Neustart durchführen des Servers, wenn das Service Handle noch gesperrt ist und der Dienst noch nicht vollständig gelöscht ist.
• Serversetup neu ausführen

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

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.