translog_corrupted_exception: translog_corrupted_exception
ElasticsearchWas bedeutet das?
Das Transaktionslog (Translog) eines Shards konnte nicht gelesen werden, weil es beschädigt ist. Während der Recovery hat Elasticsearch festgestellt, dass das Translog die Integritätsprüfung nicht bestanden hat, und der Shard konnte nicht starten.
Ursache
Translog-Dateien werden meist durch plötzlichen Stromausfall, eine volle Platte, einen Dateisystemfehler, einen Hardware-/Plattendefekt oder externe Operationen am Datenverzeichnis (Kopieren, manuelle Eingriffe) beschädigt. Auch teilweise abgeschlossene Schreibvorgänge bei einem erzwungenen Beenden (kill -9) können die Ursache sein.
Lösung
Versuche zuerst, die Daten aus einer Replica oder einem Snapshot wiederherzustellen; gibt es eine gesunde Kopie, ist der Neuaufbau des beschädigten Shards daraus der sicherste Weg. Gibt es keine andere Kopie und nimmst du Datenverlust in Kauf, stoppe den Knoten und bereinige das beschädigte Translog bzw. die Daten mit bin/elasticsearch-shard remove-corrupted-data --index <index> --shard-id <n> (dabei gehen noch nicht committete Daten dauerhaft verloren; das alte Tool elasticsearch-translog wurde in 7.0 entfernt). Das Tool gibt den Befehl POST _cluster/reroute (allocate_stale_primary, accept_data_loss: true) aus, mit dem der Shard nach dem Neustart des Knotens zugewiesen wird. Sichere vor der Operation das Datenverzeichnis. Prüfe Plattenzustand und freien Platz.
Weitere Einträge zu dieser Datenbank
- illegal_argument_exception_total_fieldsLimit of total fields has been exceeded
- verification_exceptionverification_exception: Found N problem(s) — Unknown column / Unknown index (ES|QL, SQL, EQL)
- bind_transport_exceptionbind_transport_exception (Address already in use)
- recovery_engine_exceptionrecovery_engine_exception
- snapshot_in_progress_exceptionsnapshot_in_progress_exception
- repository_verification_exceptionrepository_verification_exception
- reduce_search_phase_exceptionreduce_search_phase_exception