# Master role does not switch automaticaly

**URL:** <https://discuss.elastic.co/t/master-role-does-not-switch-automaticaly/214213>\
**Category:** Elasticsearch\
**Created:** [January 8, 2020, 10:52am UTC](https://discuss.elastic.co/t/master-role-does-not-switch-automaticaly/214213 "2020-01-08T10:52:30Z")\
**Posts on this page:** 1\
**Showing post:** 7

<div class="post-metadata">

**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:** [January 8, 2020, 12:56pm UTC](https://discuss.elastic.co/t/master-role-does-not-switch-automaticaly/214213/7 "2020-01-08T12:56:02Z")

</div>

Thanks. The vital clue is here:

`[2020-01-08T11:39:33,488][WARN][o.e.g.IncrementalClusterStateWriter] [cyres-elas03c] writing cluster state took [57674ms] which is above the warn threshold of [10s]; wrote metadata for [693] indices and skipped [0] unchanged indices`

It is taking almost a minute to write out the cluster metadata after the master is elected, which the master considers to be unreasonably slow and it therefore considers itself faulty and stands down. It's kinda right, that's a long time to write out a fairly small amount of data, but with ~700 indices it's not completely unreasonable if your disks aren't that quick.

Can you move to faster disks? If not, I suggest lengthening these timeouts to account for your environment:

```auto
cluster.publish.timeout: 90s
cluster.join.timeout: 90s

```

Work is in progress to trim down the sensitivity to slow disks in [https://github.com/elastic/elasticsearch/issues/48701](https://github.com/elastic/elasticsearch/issues/48701), hopefully to be released soon.

---

_[View the full topic](https://discuss.elastic.co/t/master-role-does-not-switch-automaticaly/214213)._
