Cloud Bigtable regional replication is Generally Available

[Misha Brukman]

[ bcc: google-cloud-bigtable-announce ]

Dear Bigtable users,

We are proud to let you know that Cloud Bigtable regional replication is Generally Available!

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

Upgrading an existing instance with a single cluster to use regional replication is as simple as clicking "Add cluster" in the GCP console:

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.

Best,

Misha

on behalf of the Bigtable team