Skip to content

SYSTEM Cited by 3 sources

VTOrc

VTOrc is Vitess's failure-scanning + leader-election component — the named elector that runs the revoke/establish protocol on MySQL primary failures in a Vitess cluster. It is a customised fork of Orchestrator (the open-source MySQL leadership-management system), inheriting Orchestrator's anti-flapping rules and topology-aware failover and adding Vitess-specific integrations:

  • etcd-backed leadership lock (via Vitess topology server) for race resolution between multiple VTOrc instances
  • VReplication workflow awareness (avoid reparent during active data-motion workflows)
  • Vitess topology publication of the current primary for downstream workflow consumers
  • Per-shard elector instances scaled across regions

Role in Vitess consensus

VTOrc is the elector in Sugu Sougoumarane's Part-5 framing ("At YouTube, each shard had fifteen eligible primaries. Having all of them scan for failures and perform active failovers was not practical. Instead, we had one agent in each region that scanned for failures and also performed leadership elections. Unsurprisingly, Vitess has also inherited this separation: VTorc is a Vitess component that acts as the elector." — sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-5-handling-races), and the anti-flapping carrier in Part-7's framing:

"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." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-7-propagating-requests)

The customised-fork framing (Part 7) is a canonical wiki disclosure the series hadn't made before — prior parts named VTOrc as the elector component but not as an Orchestrator lineage.

Deployment shape

  • One VTOrc per region (typically) — scales the failure-scanning work across regions without concentrating it.
  • Multiple VTOrcs per cluster can participate in any given leadership-change race; resolution via etcd-backed lock.
  • Per-shard reparent: VTOrc runs PlannedReparentShard for planned changes and EmergencyReparentShard for crash/partition failovers (the two operational primitives canonicalised in sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-4-establishment-and-revocation).

Observability

Vitess 21 shipped an errant-GTID count metric on VTOrc (see concepts/errant-gtid-tracking and sources/2026-04-21-planetscale-announcing-vitess-21): a precursor-of-reparent operational-visibility primitive that exposes replication divergence (transactions committed to a replica not present on the primary) before they become a reparent-blocker.

How VTOrc satisfies the propagation invariant

VTOrc inherits Orchestrator's patterns/external-metadata-for-conflict-resolution approach: rather than re-stamp every MySQL transaction with a new version on propagation, it relies on the existing GTID + timestamp metadata that MySQL's binlog replicates faithfully, and closes the residual-correctness gap through concepts/anti-flapping rules. This is an empirical rather than formal correctness argument — but validated at large scale by Orchestrator's operational track record, which VTOrc inherits.

Vitess's additional etcd-backed lock for the race-resolution layer layers a second safety on top: two VTOrcs racing to reparent must both acquire the etcd lock, so even if anti-flapping fails, the etcd lock prevents dual-electors from running concurrently.

Relationship to MySQL's native replication

VTOrc does not modify the MySQL binlog format. It operates purely at the elector layer — observing replica state, deciding failover, reconfiguring replication topology via MySQL's native CHANGE MASTER TO commands (plus Vitess's PROMOTE / DEMOTE wrappers). The MySQL replication substrate handles durability and replication; VTOrc handles the control-plane operation of changing who the leader is.

Durability plugin

Part 8 canonicalises VTOrc's durability plugin API as the first architectural recommendation of the Consensus algorithms at scale framework made concrete:

"In Vitess, we make full use of the above options and flexibilities. For example, durability rules are a plugin for vtorc. The current plugin API is already more powerful than other existing implementations. You can specify cross-zone or cross-region durability without having to carefully balance all the nodes in the right location." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts)

Canonical wiki instance of the patterns/pluggable-durability-rules pattern. The plugin expresses durability as predicates over node sets (cross-zone, cross-region, custom) rather than hard-coded majority-quorum; the comparative claim "more powerful than other existing implementations" positions Vitess as extending beyond upstream Orchestrator's durability handling. The plugin operates at the VTOrc control-plane layer — no MySQL-protocol modification required.

Structural consequence — topology elasticity: under a zone-durability plugin, adding a replica in an already-covered zone is free; the plugin constrains which intersections are valid, not how many nodes participate. This is what lets Vitess grow a shard's replica count without regressing the write-path latency.

Full-auto-pilot roadmap

Part 8 discloses Vitess's stated intent to close the tail of human-intervention cases:

"There are still a few corner cases that may require human intervention. We intend to enhance vtorc to also remedy those situations. This will put Vitess on full auto-pilot." (Source: sources/2026-04-21-planetscale-consensus-algorithms-at-scale-part-8-closing-thoughts)

Canonical VTOrc roadmap on the wiki. Part 7 previously stated "we also intend to tighten some of these corner cases to minimize the need for humans to intervene"; Part 8 escalates to the full-auto-pilot framing. The specific corner cases that still need humans are not enumerated in either part.

Seen in

Last updated · 347 distilled / 1,201 read