# ES API that return local persisted cluster state, even before it is initialized/recovered **URL:** \ **Category:** Elasticsearch\ **Created:** [July 31, 2019, 4:05pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173 "2019-07-31T16:05:23Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![itiyamas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/itiyamas/32/44685_2.png) [@itiyamas](https://discuss.elastic.co/u/itiyamas)\ **Post date:** [July 31, 2019, 4:05pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/1 "2019-07-31T16:05:23Z")
Is there an API that returns local persisted cluster state before the cluster state is recovered. I tried /\_cluster/state?local, but it does not return the persisted state on disk, if the state is not yet initialized. If there is no such API, I was wondering if it makes sense to add such an API. Thinking of a case where-in it makes debugging the cluster a lot easier when there is quorum loss. Instead of going through the logs, we can make this local API call and get the state. The persisted state is already parsed when the node boots up. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [July 31, 2019, 9:40pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/2 "2019-07-31T21:40:45Z")
You're almost certainly talking about getting the state of the system if no master has been elected, because if the master has been elected but the state has not been recovered then the cluster state API gives useful responses. However the cluster state API is probably the wrong thing to rely on for investigating election issues because it doesn't include information about the discovery process, and you'd need this. It's also documented as unstable so you shouldn't rely on it much anyway. The reason for the lack of such an API is that a sensible orchestration system should already have all the information it needs to organise a proper election. It'd only really be useful for in-depth troubleshooting, and for that kind of work it's usually more appropriate to use logs. ---
**Author:** ![itiyamas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/itiyamas/32/44685_2.png) [@itiyamas](https://discuss.elastic.co/u/itiyamas)\ **Post date:** [August 5, 2019, 12:03pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/3 "2019-08-05T12:03:52Z")
Agreed. But such an API would prove helpful during quorum loss to figure out the best surviving node by comparing term and version from the cluster state output. Right now, the only way to figure out the best surviving node is using logs. With the API, I shall be able to automate this process. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [August 5, 2019, 12:25pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/4 "2019-08-05T12:25:01Z")
I am confused. How does it help to identify the best surviving node, given that all of the surviving nodes might be stale? ---
**Author:** ![itiyamas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/itiyamas/32/44685_2.png) [@itiyamas](https://discuss.elastic.co/u/itiyamas)\ **Post date:** [August 5, 2019, 3:12pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/5 "2019-08-05T15:12:12Z")
The API can provide the cluster state metadata. The one with the highest term and cluster state version would be the latest, howsoever stale it might be, correct? ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [August 5, 2019, 3:52pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/6 "2019-08-05T15:52:33Z")
No, if you've lost half or more of the master-eligible nodes in the cluster then you may not have any copies of the latest cluster state left, and crucially you cannot even tell whether that's the case or not. All the remaining copies might be stale, and using them may lead to arbitrary data loss. The only safe way to proceed in those circumstances is to restore the cluster from a snapshot. ---
**Author:** ![itiyamas](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/itiyamas/32/44685_2.png) [@itiyamas](https://discuss.elastic.co/u/itiyamas)\ **Post date:** [August 5, 2019, 5:55pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/7 "2019-08-05T17:55:19Z")
I understand that. I am thinking of automating the [unsafe bootstrap](https://www.elastic.co/guide/en/elasticsearch/reference/current/node-tool.html#node-tool-unsafe-bootstrap) tool for my clusters. The above API will be used to decide the best surviving nodes for this tool to do a best effort recovery. ---
**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\ **Post date:** [August 5, 2019, 5:58pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/8 "2019-08-05T17:58:06Z")
> [@itiyamas](#): > > I am thinking of automating the [unsafe bootstrap](https://www.elastic.co/guide/en/elasticsearch/reference/current/node-tool.html#node-tool-unsafe-bootstrap) tool for my clusters. This is a very bad idea. ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [September 2, 2019, 6:06pm UTC](https://discuss.elastic.co/t/es-api-that-return-local-persisted-cluster-state-even-before-it-is-initialized-recovered/193173/9 "2019-09-02T18:06:32Z")
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.