SYSTEM Cited by 2 sources
Orchestrator¶
Orchestrator is the most popular open-source leadership-management system for MySQL, originally authored by Shlomi Noach at openark. It discovers replication topology, detects primary failures, and runs active failovers — playing the role of the elector in Sugu Sougoumarane's Part 7 Consensus algorithms at scale framing:
"The Orchestrator, which is the most popular leadership management system for MySQL, has built-in anti-flapping rules. These rules mitigate the above failure modes. This is the reason why organizations have been able to avoid split-brain scenarios while running MySQL at a massive scale." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests)
Role in MySQL consensus¶
MySQL on its own doesn't implement a consensus algorithm — the replication substrate is leader-based but failover is out-of-band. Orchestrator provides:
- Topology discovery: continuously scans the replica set to build a current view of who replicates from whom.
- Failure detection: heartbeat + replication-lag-based signals for primary unavailability.
- Active failover: picks a new primary from the replica set, rewires replication topology, signals the application tier.
- Anti-flapping rules: rate-limits leadership changes so that rapid back-to-back failovers don't loop into split-brain territory.
The anti-flapping layer is what makes Orchestrator production-safe. MySQL's binlog faithfully propagates the original leader's GTID + timestamp to replicas (which formally violates Sugu's per-request-new-version rule — see patterns/version-per-request-to-resolve-conflicts). Anti-flapping compensates by making the race window empirically rare.
Why this matters for the consensus framework¶
Orchestrator is the canonical production instance of the patterns/external-metadata-for-conflict-resolution pattern: rather than re-stamp every transaction with a new version on propagation, it relies on MySQL's existing GTID + timestamp metadata and closes the formal correctness gap through anti-flapping rules. The combination is empirically sufficient for large-scale MySQL deployments to avoid split-brain — validated at organisations running MySQL "at a massive scale" (Sugu's framing).
Relationship to VTOrc¶
VTOrc is a customised fork of Orchestrator used by Vitess:
"In Vitess, we use VTorc, which is a customized version of the Orchestrator, and we inherit the same safeties. But we also intend to tighten some of these corner cases to minimize the need for humans to intervene if complex failures ever happen to occur."
VTOrc inherits Orchestrator's anti-flapping + topology-aware failover, and adds Vitess-specific integrations: etcd-backed leadership locks, VReplication workflow awareness, Vitess topology publication, per-shard elector instances.
Seen in¶
- sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts — Part 8 capstone frames Orchestrator as the canonical lock-based-at-scale production instance for MySQL, and positions Vitess+VTOrc as "more powerful than other existing implementations" of the durability-plugin idea — an implicit comparative claim against upstream Orchestrator. Orchestrator provides three of the four lock-based advantages natively (graceful demotion, direct-to-leader read routing, anti-flapping); VTOrc adds pluggable durability (patterns/pluggable-durability-rules) as the fourth.
- sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests — canonical wiki introduction of Orchestrator as the external elector + anti-flapping layer that compensates for MySQL's faithful-GTID-propagation; the split-brain-avoidance-at-massive-scale framing; the VTOrc-inherits-from-Orchestrator lineage.