我们已经运行Elasticsearch几年了。我们运行了一个2节点的简单集群(1.7版)。该集群支持一些内部实用程序,因此使用率相对较低。在过去的四年中,该集群从未崩溃,重新启动甚至没有被打过。
我们决定建立一个更加注重生产的集群。我做了很多研究,这是我为新集群提出的:
2 Client Nodes (a.k.a. Coordinating nodes) [4 core, 8GB memory, 300GB HD, Virtual]
3 Master Nodes[4 core, 8GB memory, 300GB HD, Virtual]
3 Data Nodes[48 core, 64GB memory, 3TB HD (Raid 0), Physical]
该集群运行的是ES 6.5.4 CENTOS 7(我打算很快升级到7.1)。 所有节点基本上都在原始配置上运行。该集群只有大约500万个文档,而数据总量不足60GB。配置看起来像这样:
# Example Master Config
cluster.name: MYCLUSTER
node.name: MASTER01
node.master: true
node.data: false
node.ingest: false
cluster.remote.connect: false
path.repo: /repo/nfs/path
# Example Data Config
cluster.name: MYCLUSTER
node.name: DATA01
node.master: false
node.data: true
node.ingest: false
cluster.remote.connect: false
path.repo: /repo/nfs/path
# Example Client Config
cluster.name: MYCLUSTER
node.name: CLIENT01
node.master: false
node.data: false
node.ingest: false
cluster.remote.connect: false
# All have
http.port: MY_ES_PORT
discovery.zen.ping.unicast.hosts: MY_LIST_OF_SERVERS(8)
discovery.zen.minimum_master_nodes: 2
在jvm.options中,除了26G的数据节点外,所有节点的堆空间都默认为1G。
问题是我的数据节点不断崩溃。最近3天中,我的3个数据节点之一崩溃了3次。使它重新联机并消除损坏的索引片段已经花费了许多时间。我不知道是什么使它们崩溃。我在日志中看到涉及“失败的节点”和“ CorruptIndexException”的错误,但我不知道是什么导致实际节点失败。我检查了所有服务器的日志文件,尽管它们都显示错误,但似乎没有任何东西可以帮助我确定失败的原因。 3个数据节点中的2个发生故障。
互连网似乎表明最常见的原因是硬件。不幸的是,我没有看到任何证据表明硬件是问题所在。
任何人都可以就我如何找出数据节点崩溃的原因提供任何建议吗?
答案 0 :(得分:1)
“ CorruptIndexException”表示某些段已损坏。可能是因为硬盘上的坏块(坏扇区)。我建议在HDD上运行checkdisk,然后使用elasticsearch-shard工具(位于$ ELASTIC-HOME / bin /上)检查并修复损坏的段。段路径可能记录在日志文件中。
elasticsearch-shard的快速指南:
./elasticsearch-shard remove-corrupted-data --index cl6-blah-blah-index --shard-id 3
请注意,elasticsearch-shard仅在6.5上可用。
另一个重要说明:fsck和elasticsearch-shard可能导致数据丢失。尽管现在认为数据已损坏,无法恢复。