In my cluster trying to insert message (from filebeat) I get
(status=400): {"type":"illegal_argument_exception","reason":"Validation Failed: 1: this action would add [2] shards, but this cluster currently has [2999]/[3000] maximum normal shards open;"}, dropping event!
looking at the cluster health its looks like it has available shards
"cluster_name" : "elastic",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 4,
"number_of_data_nodes" : 1,
"active_primary_shards" : 1511,
"active_shards" : 1511,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 1488,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 1159,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 57267,
"active_shards_percent_as_number" : 50.3834611537179
any ideas ?
Tldr;
It seems like you only have one data node.
As you can see you have 1511 allocated shards, and 1488 unassigned shards
And guess what happens if we add them up ^^.
We get the 2999.
Elasticsearch does not allow to have the primary shards and its replicas on the same node.
But since you have only one data node all those unassigned shards are most likely replicas.
Solution
short term
Create your new index with 0 replica.
POST /my-index-000001
{
"settings": {
"index" : {
"number_of_replicas" : 0
}
}
}
You could also set all other index with no replica via:
PUT /*/_settings
{
"index" : {
"number_of_replicas" : 0
}
}
Long term
You either need to change all you indices to only have one replica or add another node. So that those replicas get allocated.
At the moment you are risking data loss of the node crash.
Then as per the documentation you can change the value of cluster.routing.allocation.total_shards_per_node which must be set a 3000
Related
I have configured an elasticsearch cluster in my kubernetes cluster (EKS), the elasticsearch cluster has 3 nodes and I have set up a 8E disk for the nodes to store the data. (thinking that I wont have any space issues for a while...)
[root#es-cluster-0 elasticsearch]# curl -s -XGET http://localhost:9200/_cat/allocation?v
shards disk.indices disk.used disk.avail disk.total disk.percent host ip node
36 66.7gb 966.1gb 8191.9pb 8191.9pb 0 10.65.32.184 10.65.32.184 es-cluster-0
33 82.6gb 966.1gb 8191.9pb 8191.9pb 0 10.65.32.202 10.65.32.202 es-cluster-2
37 76gb 966.1gb 8191.9pb 8191.9pb 0 10.65.32.178 10.65.32.178 es-cluster-1
14 UNASSIGNED
The cluster current health is:
[root#es-cluster-0 elasticsearch]# curl -s -XGET http://localhost:9200/_cluster/health?pretty
{
"cluster_name" : "k8s-logs",
"status" : "red",
"timed_out" : false,
"number_of_nodes" : 3,
"number_of_data_nodes" : 3,
"active_primary_shards" : 56,
"active_shards" : 106,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 14,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 88.33333333333333
}
I can see that I have 14 "unassigned_shards" which matches perfectly with the last line of the /_cat/allocation above
When I'm start figuring out what is happening I found this:
[root#es-cluster-0 elasticsearch]# curl -s -XGET http://localhost:9200/_cluster/allocation/explain?pretty
{
"index" : "logstash-2022.01.22",
"shard" : 0,
"primary" : false,
"current_state" : "unassigned",
"unassigned_info" : {
"reason" : "ALLOCATION_FAILED",
"at" : "2022-01-22T00:00:11.254Z",
"failed_allocation_attempts" : 5,
"details" : "failed shard on node [bf_GjmcUQGuCTk-_voh4Xw]: failed recovery, failure RecoveryFailedException[[logstash-2022.01.22][0]: Recovery failed from {es-cluster-0}{hYJ4ifx7R7yWJq6VFP3Drw}{jjAAtdcmQXeVpJXxj4DYcA}{10.65.32.184}{10.65.32.184:9300}{dilmrt}{ml.machine_memory=15878057984, ml.max_open_jobs=20, xpack.installed=true, transform.node=true} into {es-cluster-1}{bf_GjmcUQGuCTk-_voh4Xw}{QNp4DD51TQa716D4TjMFPg}{10.65.32.178}{10.65.32.178:9300}{dilmrt}{ml.machine_memory=15878057984, xpack.installed=true, transform.node=true, ml.max_open_jobs=20}]; nested: RemoteTransportException[[es-cluster-0][10.65.32.184:9300][internal:index/shard/recovery/start_recovery]]; nested: RemoteTransportException[[es-cluster-1][10.65.32.178:9300][internal:index/shard/recovery/clean_files]]; nested: UncategorizedExecutionException[Failed execution]; nested: NotSerializableExceptionWrapper[execution_exception: java.io.IOException: Disk quota exceeded]; nested: IOException[Disk quota exceeded]; ",
"last_allocation_status" : "no_attempt"
},
"can_allocate" : "no",
"allocate_explanation" : "cannot allocate because allocation is not permitted to any of the nodes",
"node_allocation_decisions" : [
{
"node_id" : "7WHft5LVTYCEWvwKM64A-w",
"node_name" : "es-cluster-2",
"transport_address" : "10.65.32.202:9300",
"node_attributes" : {
"ml.machine_memory" : "15878057984",
"ml.max_open_jobs" : "20",
"xpack.installed" : "true",
"transform.node" : "true"
},
--- TRUNCATED ---
I don't know why it's saying Disk quota exceeded if the elasticsearch cluster is reporting correctly the capacity that it has available /_cat/allocation is there any additional configuration that I need to setup in order to tell elasticsearch that we have enough space to work with ?
See here for EFS limitations that can cause disk quota error which is not necessary disk size related. Generally EFS does not support a sizeable ES stack, example elasticsearch expects 64K file descriptors per data node instance but EFS only support 32K at the moment. If you look into your elasticsearch logs there could be clue about which limitation has breached.
i've ran into the issue with unassigned searchguard shards when I've added new nodes to the ElasticSearch cluster. Cluster is located in public-cloud and has enabled awareness setting with node.awareness.attributes: availability_zone. Searchguard has enabled replica count auto-expand enabled by default. Problem reoccurs when I have three nodes in one zone and by one in two other zones:
eu-central-1a = 3 nodes
eu-central-1b = 1 node
eu-central-1c = 1 node
I do understand this is cluster configuration is kinda imbalanced, this is just replay of production issue. I just want to understand the logic of elasticsearch and searchguard. Why it is causing such issue. So here is my config
{
"cluster_name" : "test-cluster",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 8,
"number_of_data_nodes" : 5,
"active_primary_shards" : 1032,
"active_shards" : 3096,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 1,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 99.96771068776235
}
indices
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size
yellow open searchguard GuL6pHCUTUKbmygbIsLAYw 1 4 5 0 131.3kb 35.6kb
explanation
"deciders" : [
{
"decider" : "same_shard",
"decision" : "NO",
"explanation" : "the shard cannot be allocated to the same node on which a copy of the shard already exists [[searchguard][0], node[a59ptCI2SfifBWmnmRoqxA], [R], s[STARTED], a[id=d3rMAN8xQi2xrTD3y_SUPA]]"
},
{
"decider" : "awareness",
"decision" : "NO",
"explanation" : "there are too many copies of the shard allocated to nodes with attribute [aws_availability_zone], there are [5] total configured shard copies for this shard id and [3] total attribute values, expected the allocated shard count per attribute [3] to be less than or equal to the upper bound of the required number of shards per attribute [2]"
}
]
searchguard config
{
"searchguard" : {
"settings" : {
"index" : {
"number_of_shards" : "1",
"auto_expand_replicas" : "0-all",
"provided_name" : "searchguard",
"creation_date" : "1554095156112",
"number_of_replicas" : "4",
"uuid" : "GuL6pHCUTUKbmygbIsLAYw",
"version" : {
"created" : "6020499"
}
}
}
}
}
questions I have:
searchguard config said "number_of_replicas" : "4", but allocator explanations said there are [5] total configured shard copies so 5 is this with primary replica? Even if so...
what is the problem to put all these shards(3) to one zone (eu-central-1a) even if zone collapsed we would have two replicas in other zones, isn't it enough to recover?
how elasticsearch calculates these conditionals required number of shards per attribute [2]. Considering this limitation I can raise only up to 2*zones_count (2*3 = 6) for my cluster. This is really not much. Looks like there should be ways to overcome this limit.
How to solve unassigned_shards in elasticsearch?
When i run command curl -XGET 'localhost:9200/_cluster/health?pretty'
i got following result
{
"cluster_name" : "elasticsearch",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 1,
"number_of_data_nodes" : 1,
"active_primary_shards" : 145,
"active_shards" : 145,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 145,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0,
"task_max_waiting_in_queue_millis" : 0,
"active_shards_percent_as_number" : 50.0
}
As your cluster only has one node, there will always be unassigned shards - those are replica shards. They are used to restore data when a nodes crashes. They will assign to another node automaticly as soon as your cluster has two nodes. If you dont want to have them, because u are in a local development for example, you can set the replica shard size to 0 in the index mapping. You can look up how to do that here in the Update Indices Settings documentation.
I have a elasticsearch cluster with 2 data nodes with one replica node (green status). If I add a new node, the status will still be green. If I shutdown elasticsearch on the newly added node, I get a yellow status. How could I make understand to revert back to 2 nodes instead of 3 and get a green status?
Before shutdown:
{
"cluster_name" : "elastic_poiuytrez",
"status" : "green",
"timed_out" : false,
"number_of_nodes" : 5,
"number_of_data_nodes" : 3,
"active_primary_shards" : 65,
"active_shards" : 130,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 0,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0
}
curl -XGET http://localhost:9200/_cluster/settings?pretty=true
{
"persistent" : { },
"transient" : { }
}
This is what I get when I shutdown one of the node:
{
"cluster_name" : "elastic_poiuytrez",
"status" : "yellow",
"timed_out" : false,
"number_of_nodes" : 4,
"number_of_data_nodes" : 2,
"active_primary_shards" : 65,
"active_shards" : 87,
"relocating_shards" : 0,
"initializing_shards" : 0,
"unassigned_shards" : 43,
"delayed_unassigned_shards" : 0,
"number_of_pending_tasks" : 0,
"number_of_in_flight_fetch" : 0
}
Nodes settings: http://pastebin.com/wpmsRAbK (elastic-node-1 is down)
From my experience of cluster status green/yellow/red:
a) Depending on number of replicas: Some replicas have been put on the new node, and have to be recreated or moved to remaining node(s)
b) If ES ran tight on memory, and for other reasons (like removing a node) one or more replicas can go to unassigned. The cluster will be yellow until "unassigned_shards" goes down to 0
Looking at your post, notice:
"unassigned_shards" : 43,
That will cause the cluster to be in yellow status. It may take some time to get everything shuffled around on the remaining nodes.
Watching "unassigned_shards" can show you "progress toward green"
During an ElasticSearch recovery process a primary shard was lost and a replica shard was promoted but after that, when cluster tried to recover this shard
we got the following exception repeateadly:
RecoverFilesRecoveryException[[my-index][0] Failed to transfer [279] files with total size of [12.6gb]]; nested: RemoteTransportException[File corruption occured on recovery but checksums are ok]; ]]
In addition to that, the recovery of this shard response was:
{
"id" : 0,
"type" : "REPLICA",
"stage" : "INDEX",
"primary" : false,
...
"index" : {
"files" : {
"total" : 279,
"reused" : 0,
"recovered" : 262,
"percent" : "93.9%"
},
"bytes" : {
"total" : 13630355592,
"reused" : 0,
"recovered" : 7036450677,
"percent" : "51.6%"
},
And after 2 minutes
"index" : {
"files" : {
"total" : 279,
"reused" : 0,
"recovered" : 276,
"percent" : "98.9%"
},
"bytes" : {
"total" : 13630355592,
"reused" : 0,
"recovered" : 10500690274,
"percent" : "77.0%"
}
The above numbers where up/down for quite some time, but it never really recovered and cluster status remained yellow!
Is there a way to make cluster green again? Perhaps delete this replica somehow?
A dirty solution was to delete the index of the above shard and reindex again.
ES version: 1.3.1