Replication and serving graphs

Concepts

All tablets in a given shard are supposed to have the same data. They may be behind in replication, restoring from a backup, or in any other transitional state, but the goal is for them all to have the same data. Therefore, they all need to replicate in one way or another. We only support MySQL replication inside a shard at the moment.

The Replication Graph describes how the data replication flows in the tablet hierarchy. It shows who the master for the shard is, and describes which tablet is replicating from what other tablet. We only support one top level master (no multi-master setup, we probably won't change that assumption ever). All data structures are meant to handle multiple layers of replication (hierarchical replication), but it is not implemented now in the toolchain (we will eventually implement hierarchical replication). When we add a tablet to a Shard, we need to know its location in the Replication Graph, and we add it there.

The Serving Graph lists all the tablets available to serve traffic for clients. As mentioned previously, for the master, there is at most one in a shard. We try to only list healthy tablet in the serving graph. The only exception is the master: healthy or not, we should list it, as it may become healthy at any time.

The Serving Graph is generated by walking all the tablets in a Shard. Walking the Replication Graph is the best way to find all the tablets in a Shard, as every Tablet is added to the Replication Graph at creation.