干货 | Elasticsearch 运维实战常用命令清单

球友反馈的实战问题：

 

关于es的运维相关的， 遇到一些问题！

 

 •  第一个问题：是关于集群迁移的，目前需要 针对20亿的数据做迁移，如果文件迁移，需要停机时间太久，除了重新灌入，不知 道有没有更好的方式？
 •  第二个问题：我们es集群的读写都很频繁，如何把控在相互不影响性能，当前情况是会有相互影响！
 •  第三个问题：之前做版本升级，升级后部分分片不可用，但是不知道什么原因导致？
 •  最后：就是关于数据的扩容，备份，高可用这方面...... 扩容其实 面对一个问题就是你之前的es  mapping 如何建， 如果这个没规划好，增加节点的意义也不大了
 •  另外就是面对现在集群状态黄色和红色，没有体系化的思路去排查问题到底出在哪儿？

 

更多的是点对点去临时解决，积累的知识是碎片化的。

 

的确，类似问题经常被问到，是时候整合梳理一下了。

 

1.1 集群状态的含义

 •  红色：至少一个主分片未分配成功；
 •  黄色：至少一个副本分片未分配成功；
 •  绿色：全部主&副本都分配成功。

1.2 排查实战

1.2.1 查看集群状态

返回状态举例："status" : "red", 红色，至少一个主分片未分配成功。

 

1.2.2 到底哪个节点出现了红色或者黄色问题呢？

 

如下的方式，更明快直接

1.2.3 到底索引的哪个分片出现了红色或者黄色问题呢？

1.2.4 到底什么原因导致了集群变成红色或者黄色呢？

根本原因，shard分片与节点过滤类型不一致 到此，找到了根本原因，也就知道了对应解决方案。

 

1.3 扩展思考：类似 "current_state" : "unassigned",——未分配 还有哪些？

实战：

官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.2/cat-shards.html

 

未分配状态及原因解读：

适用场景：手动移动分配分片。将启动的分片从一个节点移动到另一节点。

适用场景：保证集群颜色绿色的前提下，将某个节点优雅下线。

适用场景：

 

控制在集群范围内允许多少并发分片重新平衡。默认值为2。

适用场景：

 

如果节点已从集群断开连接，则其所有分片将都变为未分配状态。经过一定的延迟后，分片将分配到其他位置。每个节点要恢复的并发分片数由该设置确定。

 

适用场景：

 

为了避免集群过载，Elasticsearch限制了分配给恢复的速度。你可以仔细更改该设置，以使其恢复更快。

 

如果此值调的太高，则正在进行的恢复可能会消耗过多的带宽和其他资源，这可能会使集群不稳定。

 

 

适用场景：如果节点达到较高的JVM值，则可以在节点级别上调用该API 以使 Elasticsearch 清理缓存。

 

这会降低性能，但可以使你摆脱OOM（内存不足）的困扰。

适用场景：为了避免在Elasticsearch中进入OOM，可以调整断路器上的设置。这将限制搜索内存，并丢弃所有估计消耗比所需级别更多的内存的搜索。

 

注意：这是一个非常精密的设置，你需要仔细校准。

适用场景：集群数据迁移、索引数据迁移等。

 

适用场景：高可用业务场景，定期增量、全量数据备份，以备应急不时之需。

 

 

文章开头的几个运维问题已经解决，其他性能相关的问题，后面会有另外的博文做梳理。

 

运维工作包罗万象，文章内容只是抛砖引玉，开了个头。

 

牛逼的集群运维需要结合可视化工具（如：kibana，cerebro，elastic-hd，Prometheus + grafana，结合业务自研工具如 阿里云Eyou等）能极大提高效率。

 

你的Elasticsearch 运维的经验、心得、体会，欢迎留言交流，我们一起完善清单。