Elasticsearch集群黄色原因的终极探秘
Elasticsearch集群颜色变黄解决方案(一)
前言
随着对ES的接触的加深,我们便会发现。其实,ES与Mysql等持久化数据库等等,如果从存储本质上来看的话。应该是没有本质上的区别的。我们进行的操作,也只有增删查改四个基本操作。ES也不会对我们的数据,默认的进行十分漂亮的操作,帮助我们完成十分漂亮的操作。
提示:以下是本篇文章正文内容,下面案例可供参考
一、Elasticsearch集群不同颜色代表什么?
- 绿色——最健康的状态,代表所有的主分片和副本分片都可用;
- 黄色——所有的主分片可用,但是部分副本分片不可用;
- 红色——部分主分片不可用。(此时执行查询部分数据仍然可以查到,遇到这种情况,还是赶快解决比较好。
二、Elasticsearch 集群颜色变黄色了要不要紧?
Elasticsearch集群黄色代表:
- 分配了所有主分片,但至少缺少一个副本。
- 没有数据丢失,因此搜索结果仍将完整。
注意:您的高可用性在某种程度上会受到影响。 如果更多分片消失,您可能会丢失数据。 将黄色视为应该提示调查的警告。
三、Elasticsearch集群健康状态如何排查?
1.集群状态查看
curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
{
"cluster_name" : "astrung",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 2,
"number_of_data_nodes" : 2,
"active_primary_shards" : 22,
"active_shards" : 22,
"relocating_shards" : 0,
"initializing_shards" : 2,
"unassigned_shards" : 20
}
2.分片状态查看
curl -XGET 'http://localhost:9200/_cat/shards?v'
index shard prirep state docs store ip node
_river 0 p STARTED 2 8.1kb 192.168.1.3 One
_river 0 r UNASSIGNED
megacorp 4 p STARTED 1 3.4kb 192.168.1.3 One
megacorp 4 r UNASSIGNED
megacorp 0 p STARTED 2 6.1kb 192.168.1.3 One
3.查看unassigned 的原因
GET /_cluster/allocation/explain
4.查看集群中不同节点、不同索引的状态
GET _cat/shards?h=index,shard,prirep,state,unassigned.reason
5.Head插件直观排查
四、Elasticsearch集群黄色的原因排查及解决方案
原因1:Elasticsearch采用默认配置(5分片,1副本),但实际只部署了单节点集群。
由于只有一个节点,因此群集无法放置副本,因此处于黄色状态。
elasticsearch 索引的默认配置如下:
index.number_of_shards:5
index.number_of_replicas:1
解决方案如下:
您可以将副本计数降低到0或将第二个节点添加到群集,以便可以将主分片和副本分片安全地放在不同的节点上。
这样做以后,如果您的节点崩溃,群集中的另一个节点将拥有该分片的副本。
(1) 设置副本数为0,操作如下:
PUT /索引名字/_settings
{
"number_of_replicas": 0
}
进行段合并,提升访问效率,操作如下:
POST /索引名字/_forcemerge?max_num_segments=1
(2) 不再物理扩展集群,将后续所有的索引自动创建的副本设置为 0。
PUT /_template/index_defaults
{
"template": "*",
"settings": {
"number_of_replicas": 0
}
}
原因2:Elasticsearch分配分片错误。
进一步可能的原因:您已经为集群中的节点数过分分配了副本分片的数量,则分片将保持UNASSIGNED状态。其错误码为:ALLOCATION_FAILED。
解决方案如下:
reroute:重新路由命令允许手动更改群集中各个分片的分配。
核心操作如下:
POST /_cluster/reroute
{
"commands": [
{
"allocate_replica": {
"index": "cs_indexs",
"shard": 0, # 重新分配的分片(标记黄色的分片)
"node": "es-2"
}
}
]
}
reroute扩展使用——可以显式地将分片从一个节点移动到另一个节点,可以取消分配,
并且可以将未分配的分片显式分配给特定节点。
举例使用模板如下:
POST /_cluster/reroute
{
"commands" : [
{
"move" : {
"index" : "test", "shard" : 0,
"from_node" : "node1", "to_node" : "node2"
}
},
{
"allocate_replica" : {
"index" : "test", "shard" : 1,
"node" : "node3"
}
}
]
}
其中:
- move代表移动;
- allocate_replica 代表重新分配;
- cancel 代表取消;
原因3:磁盘使用过载。
原因3:磁盘使用超过设定百分比85%。
cluster.routing.allocation.disk.watermark.low——控制磁盘使用的低水位线。 它默认为85%,这意味着Elasticsearch不会将分片分配给使用磁盘超过85%的节点。 它也可以设置为绝对字节值(如500mb),以防止Elasticsearch在小于指定的可用空间量时分配分片。
解决方案:
(1) 查看磁盘空间是否超过85%。
[root@localhost home]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 1014M 165M 849M 17% /boot
/dev/mapper/cl-home 694G 597G 98G 86% /home
(2) 删除不必要的索引,以释放更多的空间。
DELETE cs_indexs
原因4:磁盘路径权限问题。
原因4:磁盘路径权限问题。安全起见,默认Elasticsearch非root账户和启动。
相关的Elasticsearch数据路径也是非root权限。
解决方案:
去数据存储路径排查权限,或者在data的最外层设置:
chown -R elasticsearch:elasticsearch data
总结
如果发现es变黄了,请及时排查,不然很大可能性出现数据丢失的问题,不要问,问就是我们公司线上出过这个问题。