elasticsearch之节点重启

在elasticsearch集群中，假设NodeA因为种种原因退出集群，在NodeA上的Shard分片情况(ShardA是主分片，ShardB是某一分片副本)：

在存活节点上找到ShardA的副本，将该副本升格为主分片 由于ShardB这一分片副本丢失，所以会重新创建相应的分片副本 在存活的节点中对于分片进行再平衡
这样做的目的是保证每个分片都有足够的副本，可以避免数据丢失。需要注意的是，步骤二和步骤三牵涉到大量的网络I/O操作。

如果离开的节点重新加入集群，elasticsearch为了对数据分片(shard)进行再平衡，会为重新加入的NodeA再次分配数据分片(Shard), 这会再次导致大量的网络I/O操作。

延迟副本的重新分配

如果NodeA在离开前上面存在副本ShardB，重新加入之后还是有副本ShardB，看起来一样，但其实中间已经进行了大量的网络I/O，那么有没有办法延迟副本的重新分配呢，这样会冒丢失数据的可能(如果在NodeA重新加入之前，其它节点也挂了), 但是可以节省相应的网络开销。

延迟副本分配可以通过设置参数index.unassigned.node_left.delayed_timeout来实现，该参数动态可调，默认值是1分钟(1m)

PUT /_all/_settings

 "settings": {

 "index.unassigned.node_left.delayed_timeout": "5m"

}

上述脚本将副本重新分配延迟到5分钟之后。

查看数据分片分布情况

使用elasticsearch中的marvel插件可以很清楚的看到数据分片的分布情况，选取marvel中右上角 DashBoard 中的 Shard Allocation ， 可以看到类似于下图的分布情况：

如果日常维护elasticsearch集群，针对某一节点进行需要重启的更改，那么可以先禁止分片分配，待重启完成后，再打开：

PUT _cluster/setting

 "cluster.routing.allocation.disable_allocation": true

}

避免节点重启导致的脑裂

如果elasticsearch集群中节点数比较多，而且负载也比较高，这个时候对某一个instance进行重启，很有可能会导致该instance无法找到master而将自己推举为master的情况出现，如何防止，需要调整 elasticsearch.yml 中的内容：

discovery.zen.minimum_master_nodes: 2

discovery.zen.ping.timeout: 120s

discovery.zen.ping.multicast.enabled: false

discovery.zen.ping.unicast.hosts: ["host1","host2"]

client.transport.ping_timeout: 60s

加快recovery的进程

Elasticsearch在默认情况下将资源更多的分配给正常的traffic,这样给recovery的资源相对有限，会导致整个集群长时间处于yellow状态，如果机器配置很强劲，那么更改如下配置，可以加快elasticsearch instance重启之后的恢复过程。

cluster.routing.allocation.node_initial_primaries_recoveries: 10

cluster.routing.allocation.node_concurrent_recoveries: 5

indices.recovery.max_bytes_per_sec: 100mb

indices.recovery.concurrent_streams: 5

一个迷惑性很高的生产故障-Elasticsearch日志rotate导致节点CPU激增 Elasticsearch CPU很高的场景很常见，优化读写以及扩容即可解决问题。 如果只有一个节点CPU高，那可能的情况就比较多了，节点机器异常？读写不均匀？GC过高？forcemerge？ 这里描述一个极具迷惑性的case。
Elasticsearch 集群更换节点角色有了更快的方式 1、实战遇到的问题 问题描述：如何在一个四个节点的集群中，将主节点中的数据分散到其他节点中去，最后主节点没有数据？ 问题细节： 线上环境有4个节点，单节点为48核的物理机，252G的内存。 数据每日增量不大，累计数据就一个TB左右。数据的类型为文书类数据。 核心数据就一个索引，设置了48个分片。 只设置了一个主节点（同时是数据节点），其余三个仅数据节点。
Elasticsearch的ETL利器——Ingest节点 1、问题引出 来自星球同学的提问： “Ingest node什么场景会遇到它？ 一直没搜到它是在什么场景工作的？” 的确我们比较关心集群的节点角色的划分。包括： 集群应该几个节点？ 几个节点用于数据存储？ 要不要独立Master节点、协调节点？ 但是Ingest node的场景用的比较少。
【最佳实践】如何使用 Elasticsearch ingest 节点来丰富日志和指标 丰富化是将权威来源的数据合并到文档中的过程，当将这些数据导入到 Elasticsearch 中时，并用其他信息丰富文档，通常可以帮助我们更好的对信息进行搜索或查看数据。
【最佳实践】Elasticsearch 运用 shard filtering 实现冷热节点索引分配 在 Elasticsearch 的部署中，由于 node（节点）能力不同，会用来做不同的用途：运算能力较强的节点可以用来做 indexing（建立索引表格）的工作，而那些能力较差一点的节点，我们可以用来做搜索用途，这就是我们常说的 hot / warm 架构。
Elasticsearch的ETL利器——Ingest节点 lngest 节点的基础原理，是：节点接收到数据之后，根据请求参数中指定的管道流 id，找到对应的已注册管道流，对数据进行处理，然后将处理过后的数据，按照 Elasticsearch 标准的 indexing 流程继续运行。
Elasticsearch全观测技术解析与应用（构建日志、指标、APM统一观测平台） 立即下载