Skip to content

SYSTEM Cited by 1 source

Vitess unmanaged tablet

What it is

A Vitess unmanaged tablet (vitess.io docs) is a Vitess tablet that attaches to an externally-managed MySQL instance — one whose process lifecycle, storage, backups, and replication topology are operated by a party other than Vitess. The tablet speaks to the external MySQL over standard MySQL replication protocol and exposes it to the rest of the Vitess cluster as a regular tablet participating in a keyspace.

Normal Vitess tablets own their backing MySQL: the tablet process starts/stops the mysqld, manages data directories, handles backups via Vitess-aware tooling, and orchestrates reparenting. An unmanaged tablet explicitly renounces that ownership. It accepts an already-running MySQL, authenticates as a replication client, and leaves every other MySQL lifecycle concern to whoever is operating the external database.

Why it exists

The unmanaged tablet is the composition primitive that lets Vitess's workflow machinery operate against foreign MySQL instances without requiring them to be rehomed into Vitess first. Without it, every VReplication-based workflow (imports, resharding, MoveTables, reference-table materialisation) would require both endpoints to be Vitess-owned — which is fine for internal Vitess operations but breaks the external-onboarding case.

With it, Vitess can plug itself into the edge of a customer's existing MySQL topology without that topology knowing (or caring) that Vitess is there, beyond the fact that a standard replica has connected and is tailing binlogs.

Role in PlanetScale Database Imports

PlanetScale customer imports of external MySQL are built entirely on this primitive:

  1. Customer provides host + credentials + binlog-enabled MySQL.
  2. PlanetScale provisions an unmanaged tablet pointing at the customer's MySQL.
  3. The unmanaged tablet becomes the source tablet in a MoveTables / VReplication workflow whose targets are normal (managed) tablets inside PlanetScale.
  4. Schema routing rules initially direct queries back to the unmanaged-tablet source; after cutover they direct queries to the managed target. Reverse replication keeps the unmanaged source in sync for rollback.
  5. At detach, the unmanaged tablet is torn down and credentials deleted.

The customer's MySQL is never handed to Vitess operationally. Vitess just attaches at the replication edge.

Requirements on the external MySQL

  • Binary logs enabled (log_bin = ON) — the unmanaged tablet is a replication-protocol client; without binlogs there's nothing to tail.
  • GTIDs strongly preferred for restart semantics (file/offset replication is brittle across failover).
  • A replication-capable user with read access to the schemas being migrated plus the replication-client privileges needed to tail binlogs.

Seen in

Last updated · 319 distilled / 1,201 read