ElasticSearch的坑

2019-01-26 本文已影响152人十毛tenmao

ElasticSearch使用时，一开始因为数据量比较小，使用都比较随意，也没有在意很多参数，只要实现高可用就可以了，但是随着数据量的不断增大，过程中遇到了一系列的问题

遇到的问题

Elasticsearch创建分片的速度会随着集群内分片数的增加而变慢。以ES 5.5.2版本、3节点集群为例，在默认配置下，当集群分片数超过1w时，创建index的耗时一般在几十秒甚至以上。

ElasticSearch默认是5个分片，1个副本，相当于每创建一个索引就会产生10个分片。一开始没有问题，后来索引数目达到了4000左右（其中大部分数据量都很小，几十M而已），也就是有超过1万的分片存在，所有节点都需要维护分片和节点的关系，而且为了保证一致性，都是单线程更新，所以效率很低。

当一个节点不可达后，为了尽快恢复集群的高可用特性，ElasticSearch会尽快地重新调整分片，没有副本的，也会全量复制分片。当节点恢复后，集群又会再次重新调整分片，达到负载均衡的目的

修改延迟分配时间为5分钟

PUT _all/_settings
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m"
  }
}

当时有部分索引的主分片一直没有分配，导致集群处于red状态。当时没有仔细分析原因，只是快速地把那部分索引进行重建处理（从其他数据源导入）。当时还不知道怎么查看未分配的原因，其实可以查看分片详情命令，看到未分配的原因

#分片详情命令，查看未分配的原因
_cat/shards?h=index,shard,prirep,state,unassigned.reason&v

采用的措施有：手工分配，但是系统表示不支持命令allocate