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 practiceUpgrading 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.