2015-02-16 20 views
7

ho fatto spazio, riavviato il servizio (non va bene) e poi riavviato ma ho ancora ottenere questo nel elasticsearch.log:elasticsearch non funziona dopo la completa del disco

[2015-02-16 13:35:19,625][WARN ][cluster.action.shard  ] [Server] [logstash-2015.02.16][1] sending failed shard for [logstash-2015.02.16][1], node[PFamB-ZJS7CwSdyyAcP_8A], [P], s[INITIALIZING], indexUUID [tZ3I9HZ6TDaZSicIuGWRWQ], 
    reason [Failed to start shard, message [IndexShardGatewayRecoveryException[[logstash-2015.02.16][1] 
    failed to recover shard]; nested: TranslogCorruptedException[translog corruption while reading from stream]; nested: ElasticsearchIllegalArgumentException[No version type match [83]]; ]] 
[2015-02-16 13:35:19,625][WARN ][cluster.action.shard  ] [Server] [logstash-2015.02.16][1] received shard failed for [logstash-2015.02.16][1], node[PFamB-ZJS7CwSdyyAcP_8A], [P], s[INITIALIZING], indexUUID [tZ3I9HZ6TDaZSicIuGWRWQ], 
    reason [Failed to start shard, message [IndexShardGatewayRecoveryException[[logstash-2015.02.16][1] 
    failed to recover shard]; nested: TranslogCorruptedException[translog corruption while reading from stream]; nested: ElasticsearchIllegalArgumentException[No version type match [83]]; ]] 
[2015-02-16 13:35:43,570][DEBUG][action.index    ] [Server] observer: timeout notification from cluster service. timeout setting [1m], time since start [1m] 
[2015-02-16 13:36:10,757][DEBUG][action.index    ] [Server] observer: timeout notification from cluster service. timeout setting [1m], time since start [1m] 

Cosa devo fare?

+0

è un primario o una replica che presenta il problema? cosa significa 'curl -XGET" http: // localhost: 9200/_cat/shards? v "' show? –

+4

Ho risolto il problema spostando il modo in cui il /var/lib/elasticsearch/elasticsearch/nodes/0/indices/logstash-2015.02.16/1/translog/translog-1424037601837.recuperando ma ora mi ritrovo perso alcuni eventi come questo file era 40M? – bigfoot

+0

Ha avuto lo stesso problema dopo l'intero disco. Spostare il file .recovery dalla directory translog del nodo ha funzionato per me, ma non ho effettuato alcuna analisi se esisteva un dataloss. –

risposta

0

Ho avuto lo stesso problema, con errore "Nessun tipo di corrispondenza" nei registri.

(Inoltre, dopo il disco ha ottenuto pieno)

provato la soluzione di bigfoot per eliminare manualmente i file di recupero e ha funzionato.

Probabilmente questo può avere alcuni effetti collaterali negativi però.

5

La soluzione di Bigfoot è l'unica che sembra funzionare.

Mentre l'analisi dello stack osservato sembra essere simile a: https://github.com/elastic/elasticsearch/issues/12055

Questa richiesta di pull dovrebbe risolvere il problema: https://github.com/elastic/elasticsearch/pull/9797

Ma l'aggiornamento a v1.5.0 fa anche non fare il trucco.

Così l'unica cosa che funziona:

find /var/lib/elasticsearch/elasticsearch/nodes/ -name "*.recovering" 

ed eliminare tutti i file di recupero. Ovviamente questo ha effetti collaterali.

Problemi correlati