Skip to content

CONCEPT Cited by 2 sources

Leader establishment

Definition

Leader establishment is the act of satisfying the conditions required for a node to act as leader — i.e., to successfully complete requests on behalf of the group. Sougoumarane's canonical wiki framing: "Leadership is established when all the parameters are in place for a leader to successfully complete requests. Any change that invalidates this condition is a revocation." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-4-establishment-and-revocation).

Leadership is not a specific protocol action — it is a set of conditions that must be true. Establishment is any set of actions that makes them true; revocation is any action that makes them false.

The ordering invariant

Revocation must precede establishment. "An additional constraint is that a revoke must precede the establishment step. Otherwise, we will end up with more than one leader." If establishment happens before the old leader's conditions are invalidated, two leaders exist simultaneously — and at-most-one-leader is the entire point of single-leader consensus.

Conditions are protocol-specific

What "conditions for successfully completing requests" means depends on the protocol:

  • Paxos / Raft — the leader must own the current proposal number / term, and a majority of followers must accept writes under that proposal number.
  • MySQL semi-sync — the leader must have at least one replica acking writes; replicas must be pointed at this leader as their replication source.
  • Vitess reparenting — the new primary must be caught up with the previous primary's GTID position; the topology service must point the shard at the new primary; followers must replicate from it.

Establishment in traditional quorum algorithms is achieved by the same atomic action that revokes the old leader — pushing a new proposal number to a majority. Once you separate the two concerns, establishment becomes its own step with its own mechanism.

Interchangeable mechanisms

Just like revocation, establishment mechanisms are interchangeable across rounds as long as the invariant is satisfied: "Once revocation is complete, both algorithms have to make conditions A and B true for the new leader, which will allow for subsequent rounds to use any method of revocation."

Relationship to PRS / ERS

Vitess's two reparent operations — PlannedReparentShard (PRS) and EmergencyReparentShard (ERS) — perform establishment against a healthy replica after revocation of the old primary. The establishment steps are roughly:

  1. Select a candidate replica (caught up / compatible GTID / healthy volume).
  2. Promote it (MySQL semantics: it becomes writable and stops replicating).
  3. Update the Vitess topology service to name it as the shard's primary.
  4. Point the surviving replicas at the new primary as their replication source.
  5. Unblock the vtgate buffer / flush queued transactions to the new primary.

At this point the establishment invariant holds for the new leader and the cluster resumes serving writes.

Seen in

Last updated · 347 distilled / 1,201 read