大量更新后未分配和恢复分片

时间:2014-06-06 12:33:39

标签: elasticsearch

重磅更新后Shard将无法恢复。我能做什么?

是等待碎片恢复的问题吗?我在受影响的节点上一遍又一遍地看到这个,它恰好是主节点:

[IndexShardGatewayRecoveryException[[global][2] failed to recover shard]; nested:
ElasticsearchIllegalArgumentException[No version type match [6]]; ]]
[2014-06-06 12:32:43,249][WARN ][indices.cluster] [Centurion] [global][5] failed to start shard
org.elasticsearch.index.gateway.IndexShardGatewayRecoveryException: [global][5] failed to recover shard
    at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:241)
    at org.elasticsearch.index.gateway.IndexShardGatewayService$1.run(IndexShardGatewayService.java:132)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:744)
Caused by: org.elasticsearch.ElasticsearchIllegalArgumentException: No version type match [51]
    at org.elasticsearch.index.VersionType.fromValue(VersionType.java:307)
    at org.elasticsearch.index.translog.Translog$Index.readFrom(Translog.java:506)
    at org.elasticsearch.index.translog.TranslogStreams.readTranslogOperation(TranslogStreams.java:52)
    at org.elasticsearch.index.gateway.local.LocalIndexShardGateway.recover(LocalIndexShardGateway.java:218)
    ... 4 more

1 个答案:

答案 0 :(得分:1)

从堆栈跟踪中的org.elasticsearch.index.translog判断,这感觉就像一个损坏的事务日志,如果进程在尝试将其更新刷新到磁盘时崩溃,则可能会发生这种情况。我在Bonsai.io主持Elasticsearch时偶尔会看到类似情况。

如果删除索引translog目录的内容,您应该可以继续执行该错误并继续进行碎片恢复,但是您需要重新索引在崩溃时更新的所有文档。

为了避免将来出现这种情况,您需要对更新过程进行基准测试和调整。

最好使用Bulk API而不是单个对象更新,以实现更高效的内存管理,减少花在GC上的时间和精力。对于更新繁重的工作负载,您还需要尝试使用主分片数。我建议每个节点测试一个主分片,或者每个节点每个CPU核心测试一个主分片。