Cloud Bigtable regional replication now generally available

We are pleased to bring you Cloud Bigtable regional replication, now generally available. (If you attended Next ‘18, you got a sneak peek at this feature.) Cloud Bigtable regional replication provides a primary–primary replication between clusters in different zones within a single Google Cloud Platform (GCP) region. It is now available in all Cloud Bigtable regions with two or more zones. Cloud Bigtable is our high-performance, scalable NoSQL database service that’s especially useful when you’re performing high-volume read and write operations that require low latency. Compatibility with Apache HBase API makes migrating to Cloud Bigtable straightforward.

Using Cloud Bigtable regional replication, you can:

• Improve availability for both reads and writes with a multi-cluster routing policy, and increase availability SLA to 99.95%

• Isolate serving applications from batch analytics with single-cluster routing policies to provide each class of application with its own cluster

• Increase analytics throughput with an additional replica cluster, which can be scaled independently of the serving cluster

• Provide near-real-time backups in case of a zonal failure

Using Cloud Bigtable regional replication in practice

Alternately, you can create a new replicated instance with two clusters from the start with just a few clicks in the console or a command-line tool or API.

When you add a cluster to an existing single-cluster instance, you create a primary–primary replication setup. Here’s what will happen:

• First, all existing data will be bulk-replicated from the existing cluster to the new one

• Then, all future writes to either primary cluster will be replicated to the other replica.

Each cell value in a Cloud Bigtable table is uniquely identified by a four-tuple of (row_key, column_family, column_qualifier, timestamp). If writes are issued to different clusters with identical four-tuple parameters, upon replication, Cloud Bigtable will automatically resolve the conflict using internal metric of "last write wins," keeping a single value.

While a single Cloud Bigtable cluster is strongly consistent, it is important to remember that cross-cluster replication is eventually consistent. We provide monitoring charts so you can see the replication latency between the two clusters.

Applications using regional replication with a multi-cluster routing policy for their requests will see their Cloud Bigtable availability SLA increase from 99.5% to 99.95%, while those applications using a single-cluster routing policy will remain at 99.5% SLA, even when using regional replication.

Additionally, with this launch, we have updated the definition of the SLA from server-side availability to a user-visible error request rate, which more closely matches SLAs of other GCP database products.

For more information on the replication functionality, check out the Cloud Bigtable documentation. In particular, take a look at how you can use application profiles to route requests to a single cluster in an instance, or to any available cluster.