Examples of replication configurations

This page describes some common use cases for Bigtable replication and presents the settings that you can use to support these use cases.

This page also explains how to decide what settings to use for other use cases.

Before you read this page, you should be familiar with the overview of Bigtable replication.

Before you add clusters to an instance, you should be aware of the restrictions that apply when you change garbage collection policies on replicated tables.

In most cases, enable autoscaling for your instance's clusters. Autoscaling lets Bigtable automatically add and remove nodes to a cluster based on workload.

If you choose manual node allocation instead, provision enough nodes in every cluster in an instance to ensure that each cluster can handle replication in addition to the load it receives from applications. If a cluster does not have enough nodes, replication delay can increase, the cluster can experience performance issues due to memory buildup, and writes to other clusters in the instance might be rejected.

Examples in this document describe creating an instance, but you can also add clusters to an existing instance.

Isolate batch analytics workloads from other applications

When you use a single cluster to run a batch analytics job that performs numerous large reads alongside an application that performs a mix of reads and writes, the large batch job can slow things down for the application's users. With replication, you can use app profiles with single-cluster routing to route batch analytics jobs and application traffic to different clusters, so that batch jobs don't affect your applications' users.

To isolate two workloads:

  1. Create an instance with two clusters.

  2. Create two app profiles, one called live-traffic and another called batch-analytics.

    If your cluster IDs are cluster-a and cluster-b, the live-traffic app profile should route requests to cluster-a and the batch-analytics app profile should route requests to cluster-b. This configuration provides read-your-writes consistency for applications using the same app profile, but not for applications using different app profiles.

    You can enable single-row transactions in the live-traffic app profile if necessary. There's no need to enable single-row transactions in the batch-analytics app profile, assuming that you will only use this app profile for reads.

  3. Use the live-traffic app profile to run a live-traffic workload.

  4. While the live-traffic workload is running, use the batch-analytics app profile to run a read-only batch workload.

To isolate two smaller workloads from one larger workload:

  1. Create an instance with three clusters.

    These steps assume that your clusters use the IDs cluster-a, cluster-b, and cluster-c.

  2. Create the following app profiles:

    • live-traffic-app-a: Single-cluster routing from your application to cluster-a
    • live-traffic-app-b: Single-cluster routing from your application to cluster-b
    • batch-analytics: Single-cluster routing from the batch analytics job to cluster-c

  3. Use the live-traffic app profiles to run live-traffic workloads.

  4. While the live-traffic workloads are running, use the batch-analytics app profile to run a read-only batch workload.

Create high availability (HA)

If an instance has only one cluster, your data's durability and availability are limited to the zone where that cluster is located. Replication can improve both durability and availability by storing separate copies of your data in multiple zones or regions and automatically failing over between clusters if needed.

To configure your instance for a high availability (HA) use case, create a new app profile that uses multi-cluster routing, or update the default app profile to use multi-cluster routing. This configuration provides eventual consistency. You won't be able to enable single-row transactions because single-row transactions can cause data conflicts when you use multi-cluster routing.

Configurations to improve availability include the following.

  • Clusters in three or more different regions (recommended configuration). The recommended configuration for HA is an instance that has N+2 clusters that are each in a different region. For example, if the minimum number of clusters that you need to serve your data is 2, then you need an instance with four clusters to maintain HA. This configuration provides uptime even in the rare case that two regions become unavailable. We recommend that you spread the clusters across multiple continents.

    Example configuration:

    • cluster-a in zone us-central1-a in Iowa
    • cluster-b in zone europe-west1-d in Belgium
    • cluster-c in zone asia-east1-b in Taiwan

  • Two clusters in the same region but different zones. This option provides high availability within the region's availability, the ability to fail over without generating cross-region replication costs, and no increased latency on failover. Your data in a replicated Bigtable instance is available as long as any of the zones it is replicated to are available.

    For more information about region-specific considerations, see Geography and regions.

    Example configuration:

    • cluster-a in zone australia-southeast1-a in Sydney
    • cluster-b in zone australia-southeast1-b in Sydney

  • Two clusters in different regions. This multi-region configuration provides high availability like the preceding multi-zone configuration, but your data is available even if you cannot connect to one of the regions.

    You are charged for replicating writes between regions.

    Example configuration:

    • cluster-a in zone asia-northeast1-c in Tokyo
    • cluster-b in zone asia-east2-b in Hong Kong

  • Two clusters in region A and a third cluster in region B. This option makes your data available even if you cannot connect to one of the regions, and it provides additional capacity in region A.

    You are charged for replicating writes between regions. If you write to region A, you are charged once because you have only one cluster in region B. If you write to region B, you are charged twice because you have two clusters in region A.

    Example configuration: