场景
- 今天将elasticsearch集群的一个node下线的时候 发现unassigned shards
分析
- 遇到了Shard allocation过程中的延迟机制, 掉了节点之后, es会在一分钟之后进行下面的操作
- 将缺失主分片的一个副分片升级为主分片
- master节点补全缺少的副分片
- 各个节点上的分片的数量可能是不一致的, 分片会在各个节点上转移以达到一个新的平衡点
上述的操作 会进行大量的IO操作, 延迟一分钟是为了确定节点挂掉, 而不可以立刻上线的那种; 不然Shard allocation没有延时机制,节点立刻上线会出现大量的无用功
unassigned shards分析
- 查看unassigned shards的情况
+ curl --user elastic:yourpassword -XGET localhost:9200/_cat/shards?h=index,shard,prirep,state,unassigned.reason| grep UNASSIGNED - 场景
- Shard allocation的延迟机制
- 这个时间是可以自己调节的
- 单个索引分片的数量大于了节点的数量
- master节点会尽量的把不同的分片分配在不同的节点上, 如果分配不完也会出现unassigned shards的状态
- 这时候要么减少副本分片的数量 要么增加节点
- 在创建索引的时候, N >= R + 1这里 N 代表 node的个数, R代表你index 的副本数目
- 分片的历史数据丢失
- 节点某些数据没有副本,这个节点挂了
- Shard allocation的延迟机制