LEARN. PRACTICE. GROW.Concept and mechanism
In etcd, a majority of voting members must agree to commit changes. The rule is floor(n/2)+1: three members require two votes and five require three. An unreachable node does not automatically disappear from voting membership. Moving from three to four voters raises the majority to three and still tolerates only one member failure. These examples are not instructions for changing a production cluster. Placement and connectivity matter: an odd count does not guarantee a communicating majority in every possible partition. Three nodes separated into three groups of one cannot form a majority. Avoid turning a documentation simplification into a universal availability guarantee.
Guided application
Fencing addresses another need: preventing a node from running a resource when leaving it active is unsafe. In the Pacemaker example, a silent node may still write to storage; starting another writer without isolation can create divergence. The mechanism must not depend on a healthy target. Using SSH to request shutdown cannot guarantee action when the system is stuck. Also analyze fencing control networking and power, because a shared failure can remove the recovery capability itself. In a fictional incident, cut-off pressure does not establish that the old writer stopped. Record isolation evidence, apply the supported procedure, and communicate delay before permitting another write authority.
Five voters, three communicating: a majority exists. Three isolated groups of one: none exists.
Common pitfalls
Silence as shutdown; odd count as guaranteed majority; extra vote as extra tolerance; fencing channel sharing the failure.
Related topics: Objectives and service impact · Failure domains and residual capacity · Replication, promotion, and redundancy
Recover authority only with understood membership, connectivity, and isolation.
Reference: Pacemaker 3.0 fencing and isolation · DR HA 2026-09; Pacemaker 3.0, etcd 3.6, PostgreSQL 18 and selected Kubernetes/AWS behavior