Learn Vitess - Multi-region & Disaster Recovery

#Introduction

Up to episode 13, your cluster lived in one location. Episode 14 takes Vitess to global scale: data spread across several regions, Indonesian users served from a nearby region, and if one region falls, service continues from another. This is the difference between "high availability" and "surviving a disaster".

Episode 14 roadmap: geo-sharding, multi-region replication and read locality, disaster recovery strategies, then global failover planning. By the end, you'll have a blueprint for designing multi-region Vitess.

#Geo-sharding for Multi-region

Geo-sharding is a pattern for placing data based on user location. Shards are created per region or per country — for example, a shard for Southeast Asia, a shard for Europe, and so on — with a sharding key that reflects location (e.g., region_id or country_code).

The main benefit of geo-sharding: data proximity. Users are served by data that's physically close, so latency drops dramatically. In addition, data subject to local regulations can stay in the required region — for example, Indonesian user data must be stored in Indonesia.

{
  "sharded": true,
  "vindexes": {
    "region_hash": { "type": "region_experimental" }
  },
  "tables": {
    "users": {
      "column_vindexes": [
        { "column": "region_id", "name": "region_hash" }
      ]
    }
  }
}

The VSchema above maps region_id to shards with a region vindex. Vitess provides dedicated vindexes for this pattern, such as region_experimental, which ties a region to a specific group of shards.

#Multi-region Replication and Read Locality

Geo-sharding arranges writes; multi-region replication arranges availability. Every shard in one region can be replicated to another region as a cross-region replica — write data is duplicated so if the primary region falls, another region has a copy.

Read locality is the ability to direct read queries to the tablet closest to the client. Vitess supports this through cells and tablet filtering configuration: a client in the Jakarta cell reads from a replica in Jakarta, not from a distant region.

vtctlclient ListAllTablets -cell jkt,sin

vtctlclient ListAllTablets with a cell argument displays tablets in specific cells. VTGate uses this info to pick the nearest tablet when serving reads.

To direct reads to the local cell, configure VTGate with flags like:

vtgate:
  extraFlags:
    cells_to_watch: jkt,sin
    tablet_filters: "-keyspace:commerce"

cells_to_watch tells VTGate which tablets it may use — reads will be directed to the local cell as long as there's a healthy tablet there.

#Disaster Recovery Strategies

Disaster recovery (DR) answers: how do we keep operating if a region is completely destroyed? Two key metrics:

• RTO (Recovery Time Objective) — how long the service can be down.
• RPO (Recovery Point Objective) — how much data may be lost.

Vitess enables several DR patterns:

• Active-Passive (low RPO, RTO in minutes): one active region, one standby with replicated data. If the primary region falls, failover to the standby. RPO approaches zero if replication is synchronous; RTO depends on promotion speed.
• Active-Active: two regions serve traffic concurrently, usually with geo-sharding so the same data isn't written in two places. RTO is very low.
• Backup-restore (RPO in hours): if replication can't catch up, restore from backup. Slowest, but simplest.

#Global Failover Planning

Global failover is a team exercise, not just a command. Planning includes:

• Failover runbook: step by step, who does what, and how long each step takes.
• Data promotion: make sure the standby region has the freshest data before making it primary.
• Traffic shift: how users are directed to the new region — usually via DNS or a global load balancer.
• Communication: who announces the incident and how updates are distributed.

vtctlclient ListAllTablets -cell jkt,sin,sgp
vtctlclient ListShardHealth -cell jkt,sin,sgp

The vtctlclient ListShardHealth command shows shard health across all cells — the first step in a quick assessment when a region is in trouble. Promoting a primary in the standby region uses the reparenting commands you already know from episode 6:

vtctlclient EmergencyReparentShard -keyspace_shard=commerce/0 \
  -new_primary=<tablet-sin>

vtctlclient EmergencyReparentShard designates a tablet in the standby region as the new primary. In an active-passive pattern, this is the heart of global failover.

#Closing

In this episode 14 you understood how to take Vitess to global scale: geo-sharding to place data close to users, multi-region replication with read locality, three DR strategy patterns (active-passive, active-active, backup-restore), and global failover planning with a runbook.

Key takeaways:

• Geo-sharding places data near users through a location-based sharding key.
• Cross-region replicas give other regions a copy of the data.
• Read locality directs reads to the nearest cell via cells_to_watch.
• Set your RTO and RPO targets before choosing a DR pattern.
• Asynchronous cross-region replication has an RPO above zero — know the risk.
• Global failover needs a runbook, practice, and communication — not just a command.

In the next episode, episode 15, we speed everything up: performance optimization — tuning queries with indexing and vindexes, VTGate connection pooling, VTTablet resource tuning, and MySQL innodb and storage settings. See you there!