elasticsearch系列四：集群常规运维

概述

在使用es中如果遇到了集群不可写入或者部分索引状态unassigned，明明写入了很多数据但是查不到等等系列问题该怎么办呢？咱们今天一起看下常用运维命令。

案例

起初我们es性能还跟得上，随着业务发展壮大，发现查询性能越来越不行了，我们可以通过cat api查看索引的segments情况，比如下图：

如果发现索引的segment段过多，并且每个段数据量很小，那么就可以通过合并段的措施来提升检索性能。

那么我们在大批量迁移的时候，发现数据明明写入了但是少了很多？这是为什么呢，咱们还是可以通过cat api查看下线程池的状态，如下图：

通过查看写入线程池的状态观测是不是达到集群最大写入能力了，导致线程池执行了拒绝策略等等。更多的线程池说明可见官方文档：https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

还可以通过cat查看集群中节点数据分配情况如图：

上面都是介绍的cat api的使用方法，那么对于有的索引状态、集群状态不正常的时候我们怎么分析原因呢？这时候就得通过cluster api了，比如诊断当前集群什么不健康，如下图：

比如我们得到如下原因：

The node containing this shard copy recently left the cluster. Elasticsearch is waiting for it to return. If the node does not return within [%s] then Elasticsearch will allocate this shard to another node. Please wait.

那通过这个结果我们就可以清晰的了解到原来这个索引之所以是unassigned状态是因为，持有它的节点离开了集群，也就是说有个节点可能down了和集群失去联系了。之前在中国电信就遇到过类似问题，由于集群中某个节点物理内存出现问题，未接到通知运维同事就临时停机修复了，当时集群部分索引状态就unassigned，也是通过explain查询到有一台物理节点失去联系了，联系运维同事后才知有一台集群出现了问题，好在当时只是存储了日志数据，停掉了所有的logstash，关闭了集群rebalance和自动分配功能，防止大量磁盘数据移动。

待该节点恢复后再开启rebalance和自动分配功能，开启logstash消费囤积在kafka中的日志数据。

包括我们升级es集群的时候也需要先关闭以上两个功能，具体api如下：

cluster.routing.allocation.enable ：

all - （默认值）允许为所有类型的分片分配分片。

primaries - 仅允许分配主分片的分片。

new_primaries - 仅允许为新索引的主分片分配分片。

none - 任何索引都不允许任何类型的分片。

cluster.routing.rebalance.enable

all - （默认值）允许各种分片的分片平衡。

primaries - 仅允许主分片的分片平衡。

replicas - 仅允许对副本分片进行分片平衡。

none - 任何索引都不允许任何类型的分片平衡。