Introducing Spanner dual-region configurations that help maintain high availability and data residency

Spanner is Google’s fully managed, globally distributed database with high throughput and virtually unlimited scale. Spanner processes over 4 billion queries per second at peak. With features such as automatic sharding, zero downtime, and strong consistency, Spanner powers demanding, global workloads — not only across customers in financial services, gaming, retail, and other industries but also Google internally — that are both relational and non-relational.

Previously, to maintain data residency in countries with only two Google Cloud regions, you were restricted to regional Spanner configurations with 99.99% availability. That’s because Spanner multi-region configurations require three regions, one of which would be located outside the country. You can now take advantage of Spanner’s industry-leading 99.999% availability while complying with data residency requirements using the new Spanner dual-region configurations. The new dual-region configurations - now available in Australia, Germany, India, and Japan - help ensure your data resides within the selected country.

Under the hood and managing failovers 

The Spanner dual-region configurations are built from the ground up to help ensure that we can offer the same high availability and zero recovery-point objective (RPO) guarantees as the Spanner multi-region configurations that typically span across three different regions. 

Let’s take an example of a dual-region configuration and examine a Spanner instance running in the newly launched configuration in India. These instances replicate data to Mumbai and Delhi. Each of the two regions contains three replicas, two of which are read/write replicas and one of which is a witness replica. For both regions combined, the Spanner instance contains a total of six replicas. This configuration is called dual-region mode.

In the event of a zone outage affecting one of the three replicas in a region, Spanner still runs in dual-region mode, where Spanner still maintains a quorum of at least two replicas in each region, helping ensure your database remains available in case of a zonal outage.

In the unlikely scenario of an outage of an entire region, databases lose availability if they are still in dual-region mode. To recover availability, databases must switch to single-region mode, consisting of three replicas in a single region.

This switch or failover can occur in two ways. 

First, Google continuously monitors for region outages and upon detection, automatically fails over and reconfigures your entire dual-region configuration instance to single-region mode that continues to run in the unaffected region. 

Second, we are also making available a health dashboard in System Insights to help you detect conditions when latency or availability thresholds are breached. This allows you to manually initiate a failover to the single-region mode by issuing a reconfiguration request via the change-quorum API in gcloud CLI. Spanner continues to offer zero-RPO for regional failure.

Note that if you perform a manual failover, you need to also perform a manual failback once the affected region has recovered, otherwise your instance continues to be in single-region mode, which has lower availability.

Getting started with Spanner dual-region configurations

When creating a new Spanner instance, you can choose the newly available dual-region configurations in the Google Cloud console.

In addition to creating new Spanner instances, you can also migrate your existing regional or multi-regional configurations using the recently launched Spanner’s self-serve instance move service. Moving your instance doesn't incur any downtime, and Spanner continues to provide the usual transaction guarantees, including strong consistency, during the move.

We’re very excited for you to try out Spanner dual-region configurations. You can read more details in our public documentation here. 

Learn more about Spanner and create a 90-day Spanner free trial instance.