# UnavailableShardsException occurs spontaneously when indexing

**URL:** <https://discuss.elastic.co/t/unavailableshardsexception-occurs-spontaneously-when-indexing/141793>\
**Category:** Elasticsearch\
**Created:** [July 26, 2018, 2:16pm UTC](https://discuss.elastic.co/t/unavailableshardsexception-occurs-spontaneously-when-indexing/141793 "2018-07-26T14:16:51Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![wassx](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wassx/32/24440_2.png) [@wassx](https://discuss.elastic.co/u/wassx)\
**Post date:** [July 26, 2018, 2:16pm UTC](https://discuss.elastic.co/t/unavailableshardsexception-occurs-spontaneously-when-indexing/141793/1 "2018-07-26T14:16:52Z")

</div>

Hi, I have an **ES 6.3.1** running in a **docker container** with a **volume** where data is stored.  
I post images as base64 in the doc which worked **very well over the last year**.

It could be by hazard that, after an backup and restore with volumerize of the data volume, suddenly this exception occurrs:

```
[2018-07-26T13:54:35,803][WARN][r.suppressed] path: /attachments/attachment/upload-1532613215528, params: {refresh=true, index=attachments, id=upload-1532613215528, type=attachment, timeout=1m}
elasticsearch | org.elasticsearch.action.UnavailableShardsException: [attachments][0] primary shard is not active Timeout: [1m], request: [BulkShardRequest [[attachments][0]] containing [index {[attachments][attachment][upload-1532613215528], source[n/a, actual length: [672.8kb], max length: 2kb]}] and a refresh]
elasticsearch | at org.elasticsearch.action.support.replication.TransportReplicationAction$ReroutePhase.retryBecauseUnavailable(TransportReplicationAction.java:928) [elasticsearch-6.3.2.jar:6.3.2]

```

As far as i found in other forum posts, it could be due to massive shard counts or immediately following actions. I have 10 shards for this index (standard settings) and local network (no network related timeout, running on same machine).

Any ideas please where I can look into to get a better insight, what could cause the problem?

EDIT:  
I found a proposed solution to request a healthcheck for an active shard.

```
ClusterHealthRequest healthRequest = new ClusterHealthRequest();
					healthRequest.waitForActiveShards(1);

					try {
						ActionFuture<ClusterHealthResponse> health = ConnectorManager.getTransportClient().admin().cluster().health(healthRequest);
						ConnectorManager.getElastic().index(indexRequest);
					} catch (IOException e) {
						response.sendError(503, e.getLocalizedMessage());
						LOG.error(e.getLocalizedMessage(), e.getCause());
						throw new IOException(e);
					} catch (Exception e) {
						response.sendError(503, e.getLocalizedMessage());
						LOG.error(e.getLocalizedMessage(), e.getCause());
						throw new IOException(e);
					}

```

But all i get is an exception with:  
`None of the configured nodes are available: [{#transport#-1}{toFzQQVmRK2g4DKkhAbMNQ}{localhost}{127.0.0.1:9300}]` The port for 9300 is exposed on the docker container for ES.

EDIT II:  
Checking the cluster health of affected index it says RED but gives me a vage clue:  
{  
"cluster\_name": "docker-cluster",  
"status": "red",  
"timed\_out": false,  
"number\_of\_nodes": 1,  
"number\_of\_data\_nodes": 1,  
"active\_primary\_shards": 3,  
"active\_shards": 3,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 7,  
"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": 48.76543209876543,  
"indices": {  
"attachments": {  
"status": "red",  
"number\_of\_shards": 5,  
"number\_of\_replicas": 1,  
"active\_primary\_shards": 3,  
"active\_shards": 3,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 7,  
"shards": {  
"0": {  
"status": "red",  
"primary\_active": false,  
"active\_shards": 0,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 2  
},  
"1": {  
"status": "red",  
"primary\_active": false,  
"active\_shards": 0,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 2  
},  
"2": {  
"status": "yellow",  
"primary\_active": true,  
"active\_shards": 1,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 1  
},  
"3": {  
"status": "yellow",  
"primary\_active": true,  
"active\_shards": 1,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 1  
},  
"4": {  
"status": "yellow",  
"primary\_active": true,  
"active\_shards": 1,  
"relocating\_shards": 0,  
"initializing\_shards": 0,  
"unassigned\_shards": 1  
}  
}  
}  
}  
}

---

<div class="post-metadata">

**Author:** ![wassx](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/wassx/32/24440_2.png) [@wassx](https://discuss.elastic.co/u/wassx)\
**Post date:** [July 27, 2018, 8:05pm UTC](https://discuss.elastic.co/t/unavailableshardsexception-occurs-spontaneously-when-indexing/141793/2 "2018-07-27T20:05:37Z")

</div>

Problem temporarily solved. I reindexed the index and all the shards went to yellow. Still have not found the causing issue why the shards went red.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [August 24, 2018, 8:05pm UTC](https://discuss.elastic.co/t/unavailableshardsexception-occurs-spontaneously-when-indexing/141793/3 "2018-08-24T20:05:52Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
