概述
在使用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 - 任何索引都不允许任何类型的分片平衡。
cluster.routing.allocation.allow_rebalance
all 始终 - 始终允许重新平衡。
indices_primaries_active - 仅在所有主分片激活时。
indices_all_active - (默认)仅当所有分片都激活时。
对于升级完后的集群或者部分节点正常后的es来说可能会发生数据恢复,那么这个时候如果想最短时间恢复完成,可以通过设置集群的并发度:
cluster.routing.allocation.node_concurrent_recoveries
该值最好等于磁盘的数量(对于raid0来说)。
总结
我们想要更好的使用es不能只注意查询语法的书写,需要全访问的深入的了解es,建议从头到尾过一遍官方文档,毕竟只有目前最了解孩子。
Elasticsearch系列经典文章