# It is too easy to break master quorum

**URL:** <https://forum.yugabyte.com/t/it-is-too-easy-to-break-master-quorum/4940>\
**Category:** General\
**Created:** [February 6, 2026, 10:29am UTC](https://forum.yugabyte.com/t/it-is-too-easy-to-break-master-quorum/4940 "2026-02-06T10:29:30Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![hispebarzu](https://avatars.discourse-cdn.com/v4/letter/h/9de053/32.png) [@hispebarzu](https://forum.yugabyte.com/u/hispebarzu)\
**Post date:** [February 6, 2026, 10:29am UTC](https://forum.yugabyte.com/t/it-is-too-easy-to-break-master-quorum/4940/1 "2026-02-06T10:29:30Z")

</div>

Basically same as [Cannot add or remove masters when master is dead · Issue #5211 · yugabyte/yugabyte-db · GitHub](https://github.com/yugabyte/yugabyte-db/issues/5211)

IMO, this is a an unintuitive from operations perspective and quite hard to debug when happens.  
Compared to something like cockroach where cluster is able to detect node replacements and heal by itself. If -master-adresses changed and no longer include dead master, yugabyte probably should automatically start remote bootstrap for new master from the two old ones.

---

<div class="post-metadata">

**Author:** ![dorian\_yugabyte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.yugabyte.com/dorian_yugabyte/32/206_2.png) [@dorian\_yugabyte](https://forum.yugabyte.com/u/dorian_yugabyte)\
**Post date:** [February 6, 2026, 10:54am UTC](https://forum.yugabyte.com/t/it-is-too-easy-to-break-master-quorum/4940/2 "2026-02-06T10:54:31Z")

</div>

Hi @hispebarzu

Can you deploy with [yugabyted reference | YugabyteDB Docs](https://docs.yugabyte.com/stable/reference/configuration/yugabyted/) ?

It keeps yb-master processes ready to join the cluster when you lose em.

Will that fix it for you?