CONCEPT Cited by 1 source

Replica creation from backup¶

Definition¶

Replica creation from backup is the production technique of seeding a new replica by restoring a recent backup onto a fresh empty server and then catching up via replication — rather than having the new replica re-replicate the entire database from the primary over the replication channel.

Once the new replica is caught up to the current GTID position, it joins the replication topology as a live replica serving HA and/or read traffic.

Why it matters (non-obvious backup role)¶

A canonical production insight from the 2024-07-30 PlanetScale post (Source: sources/2026-04-21-planetscale-faster-backups-with-sharding): backups are not just for disaster recovery — they're the load-bearing primitive for replica creation after primary failover.

The typical Vitess HA flow when a primary fails:

Primary dies.
An existing replica is promoted to primary (zero-downtime reparent).
The cluster is now short one replica — promotion consumed one of the existing replicas.
A new replica needs to be created to restore the target replica count.

Step 4 is where backup-as-seed becomes load-bearing. Verbatim:

"Backups are needed when creating a new replica. When the primary goes down, we promote a replica to a primary, but now we need a replacement replica! To do this, Vitess spins up a new empty replica server, restores a backup to that server, then points it to the primary to get caught-up via replication. Without the ability to restore from backup, the new replica would need to replicate the entire database from the primary. This would take a long time and have a negative impact on performance. Backups allow for new replica creation to happen with less negative performance impact on the primary."

Relationship to the backup architecture¶

The same backup architecture used to take backups is inverted at replica-creation time: instead of "restore previous backup → catch up via replication → take new backup," the flow is "restore recent backup onto a new server → catch up via replication → serve as live replica."

The backup in object storage is the durable bootstrap image for both operations.

Alternative (without backups)¶

Without backup-as-seed, replica creation forces a full replication stream of the entire database from the primary. For multi-TB databases, this is:

Slow — hours to days at replication bandwidth.
Expensive on the primary — the primary sends every row it has, on top of serving production traffic + replicating to existing replicas.
Fragile — any network blip during hours-long replication may force a restart.

Backup-as-seed converts this into a small catchup delta (bounded by how recent the last backup is), shifting the bulk of the data transfer from "primary → new replica" to "object storage → new replica."

Shard-parallel property¶

Under shard-parallel backup, replica creation also parallelises per-shard: each shard independently restores its own backup onto its own new replica server, then catches up from its own primary. Replacing a replica across all 32 shards happens N-way in parallel, not serially.

Caveats¶

Catchup delta matters. If the most recent backup is stale, the replica has more binlog to replay — which still comes from the primary. The shorter the backup cadence, the cheaper the replica-creation operation.
Backup compatibility. The backup format must match what the new MySQL instance can restore. Vitess's builtin physical-backup engine is typically compatible across minor MySQL versions but not across major.
Retention requirements. Binlog retention must cover the gap between the most recent backup and the current GTID position, or catchup cannot complete.

Seen in¶

sources/2026-04-21-planetscale-faster-backups-with-sharding — canonical wiki disclosure. Names replica creation as one of the three load-bearing production uses of backups (alongside disaster recovery and PITR). The structural insight that "backups reduce primary-load during post-failover replica creation" is the key takeaway.