How To Achieve Region-Level Fault Tolerance While Using Row-Level Geo-Partitioning?

Distributed SQL Tips and Tricks

June 8, 2023

YugabyteDB uses the PostgreSQL concept of tablespaces to allow users to group nodes together in order to control data placement for tables and indexes.

There are two main configurations for this type of functionality, which we refer to as row-level geo-partitioning. The first is for data residency compliances such as GDPR. If using geo-partitioning specifically for data residency use cases then you can only achieve availability zone level fault tolerance. By design, you do not want your data to leave that region. However, for use cases where you prefer region level fault tolerance or you have a need for a “global” table, you can configure your tablespaces to have a replica in multiple regions.

“Global” tables are an interesting concept because they allow you to have region-level fault tolerance, and also allow you to get low latency reads in each region for the same set of data.

You can accomplish this by setting a tablespace to have replicas in every region and enabling follower reads. This allows you to lower read latencies by taking advantage of the data placement on local YugabyteDB nodes. These reside in the same region that your apps are running in, no matter which region the tablet leader resides in.

Let’s consider a cluster deployment with nodes across five different regions, spanning multiple continents. For data with data residency requirements you can use regionalized tablespaces to define data placement only within the allowed regions. For “global” tables, which are accessed from all regions and contain data without those restrictions, you can define data placement in all regions with another tablespace. This can be accomplished thanks to tablespaces, allowing you to define replication factors independent of the default cluster replication factor, which is usually 3. In this case you would set “num_replicas”: 5 in your tablespace placement policy. Such deployments are in use for production workloads with YugabyteDB today.

NOTE: follower reads should only be enabled if your use case allows for stale reads, including those to the tablet leader. This also has an impact on write latency, which will be slightly higher for two reasons.

First, the client has to be as close as possible to the tablet leader. Since the leader can only exist in one region, the regions with tablet followers will see a higher network latency impact.

Second, the quorum commit needs to wait for data to get replicated to a second region. This means that you will incur the latency impact of the necessary quorum acknowledgement from that second region.

For additional information on geo-distribution in YugabyteDB I recommend you check out a great blog series on dev.to called Local reads in geo-distributed YugabyteDB by our very own Franck Pachot.