Design, migrate, and run scalable, highly available databases on Google Cloud across relational and NoSQL services, and track your readiness for the Professional Cloud Database Engineer exam.
Prepare and test your skills
Prepare and test your skills
High availability for relational workloads means the database stays reachable when a zone or instance fails. Cloud SQL (opens in a new tab) provides this with a regional instance that places a primary instance in one zone and a standby instance in a second zone of the same region. All writes are protected by synchronous replication, and control automatically shifts to the standby when the primary can no longer serve traffic.
Cloud SQL high availability (HA) configuration is a regional instance made of a primary instance in a primary zone and a standby instance in a secondary zone within the same region. The regional instance removes a single point of failure because a zone outage affects only one of the two database copies. An HA-configured instance costs twice as much as a standalone instance for CPU, RAM, and storage, and support for regional persistent disk with at least one dedicated CPU carries full Service Level Agreement (SLA) coverage.
Synchronous replication in Cloud SQL is the process that copies every write from the primary instance to persistent disks in both zones before the transaction is reported as committed. Data flows from the primary instance to the disk in the primary zone and to the disk in the secondary zone, and the commit succeeds only after both copies are durable. This order means the standby instance holds the same committed data as the primary, which supports a zero or near-zero Recovery Point Objective (RPO) within the region.
Automatic failover in Cloud SQL is the process where the standby instance becomes the new primary instance and client connections are rerouted to it after an instance or zone failure. The failed primary does not automatically take over again when it recovers, so applications continue on the promoted instance without another interruption. A failback uses the same steps in the opposite direction to move traffic back to the original zone when desired.
The failover lifecycle proceeds in order:
Exam tip: A failover promotes the standby to primary, while a restart keeps the same primary; if the Operations log shows Restart instead of failover, the cause was an instance-level issue such as exhausted memory, not a zone or instance failure.
Cross-region replicas in Cloud SQL are readable copies placed in a different region that can be promoted to primary if the entire primary region is lost. Data flows from the regional primary instance to the cross-region replica, and promotion makes the replica the new primary for production traffic. Because a read replica can be configured for HA in advance, the promoted replica already has its own primary and standby across zones and does not need extra HA changes after promotion.
Cascading replicas extend this protection by giving a read replica its own cross-region replica. The chain flows from the primary region to the first replica region and then to a second replica region, so immediate protection remains after the first promotion. This design provides a near active-active topology with read replicas across zones and an RPO between regions that is close to zero.
High availability (HA) and disaster recovery (DR) in Cloud SQL use different scopes and replication to meet different recovery goals. HA protects a regional deployment against zone failure, while DR protects a multi-region deployment against region failure. The differences determine whether failover is automatic and how much data loss and downtime to expect.
| Approach | Scope | Replication | Recovery objective |
|---|---|---|---|
| High availability | Single region, multiple zones | Synchronous replication between primary and standby zones | Zero or near-zero Recovery Time Objective (RTO) and RPO with automatic failover and no single point of failure |
| Disaster recovery | Two or more regions | Typically asynchronous replication to a secondary region | Non-zero RTO and RPO that depend on replication lag, with manual or semi-automated promotion of a cross-region replica |
Choose HA when business continuity requires automatic survival of a zonal outage inside one region. Choose DR with cross-region replicas when survival of a regional outage is required, and test the promotion path regularly because failover across regions involves replication lag and client reconnection decisions.
Multi-cluster replication and traffic routing in Bigtable (opens in a new tab) is the combination of storing independent copies of data in multiple clusters and controlling how application traffic reaches those clusters. A Bigtable instance holds one or more clusters, and each cluster lives in a single zone. When an instance has more than one cluster, Bigtable automatically replicates writes between clusters so each cluster holds a separate copy of the data.
Bigtable replication is the automatic synchronization of data between all clusters in the same instance without manual copying. Production instances require a minimum of two clusters in unique zones in a region, which protects data if one zone fails. Because each zone with a cluster holds an independent copy, incoming traffic can fail over to another cluster in the same instance when a cluster, zone, or region becomes unavailable.
Replication can stay inside one region or span multiple regions. Replication within the same region avoids cross-region replication charges and avoids added latency on failover. Replication between regions adds geographic redundancy but incurs a charge for replicating writes between regions.
Multi-cluster routing is the app profile setting that lets Bigtable automatically send requests to the nearest healthy cluster and fail over if needed. An app profile controls which clusters an application can use, and you enable this mode by creating a new app profile that uses multi-cluster routing or updating the default app profile to use it. This mode provides eventual consistency, which means recent writes may briefly appear different on different clusters, and single-row transactions cannot be enabled because they can cause data conflicts under multi-cluster writes.
Client placement is part of high availability with multi-cluster routing. To stay available during a regional failure, locate application clients in or near more than one of the regions where the Bigtable clusters live. Data enters the Google Cloud network through the region closest to the application server, so clients in only one region can still lose access even if Bigtable data remains available elsewhere.
Single-cluster routing is the app profile setting that pins all requests from an application to one specified cluster. The specified cluster handles all incoming reads and writes, while the other clusters in the instance receive replicated copies as a near-real-time backup. Choose single-cluster routing when the application cannot afford to read stale data and needs every read to come from the same copy.
Failover with single-cluster routing is manual rather than automatic. If the serving cluster becomes unavailable, you change the app profile to point to the backup cluster to minimize downtime. This pattern still gains durability from replication, but it does not gain automatic traffic shifting between clusters.
A Bigtable cluster layout is the placement of clusters across zones and regions that balances survival of zone and region failures against replication cost and latency. The recommended configuration for high availability is N+2 clusters in different regions, where N is the minimum number of clusters needed to serve the workload. For example, if 2 clusters are needed for capacity, use 4 clusters so service continues even in the rare case that two regions become unavailable, ideally spread across multiple continents.
| Layout | Availability benefit | Cost and performance tradeoff |
|---|---|---|
| Three or more regions, one cluster each | Survives loss of one or two regions; recommended for highest availability | Charged for replicating writes between regions; higher cross-region latency |
| Two clusters in one region, different zones | Survives zonal failure with failover inside the region | No cross-region replication charge and no increased latency on failover; data is unavailable if the whole region is unreachable |
| Two clusters in two different regions | Survives loss of one region | Charged for replicating writes between regions |
| Two clusters in region A plus one cluster in region B | Survives loss of one region and adds capacity in region A | Charged for cross-region replication; a write to region A replicates once to region B, while a write to region B replicates twice to region A |
Exam tip: Choose multi-cluster routing for automatic failover with eventual consistency and no single-row transactions; choose single-cluster routing when all reads must go to one cluster and failover will be manual.
Cloud Spanner (opens in a new tab) is a managed database service that can run as a regional or multi-regional resource to keep applications available during zone and region failures. A regional instance keeps data and serving capacity inside one region with redundancy across zones, while a multi-regional instance spreads replicas across multiple regions to survive the loss of an entire region. Applications connect to the Spanner instance from compute tiers in each region, so a regional outage does not require moving or restoring the database.
Regional and multi-regional availability models in Cloud Spanner define where Google Cloud runs the database infrastructure and which failures the database can survive. In the regional model, the infrastructure is located in a specific region and is managed to be redundantly available across all zones in that region, so traffic automatically serves from another zone if one zone becomes unavailable. In the multi-regional model, the infrastructure is located in several regions, so the service can withstand the loss of an entire region, typically at the cost of higher latency.
| Model | Failure protection | Latency and cost tradeoff |
|---|---|---|
| Regional | Survives zonal failure within one region | Lower latency, cannot serve if the whole region is lost |
| Multi-regional | Survives zonal failure and full region loss | Higher latency, protects cross-region workloads |
Choose the multi-regional model when the Recovery Point Objective (RPO) and Recovery Time Objective (RTO) require continuous writes and reads during a regional interruption.
Replica placement in Cloud Spanner is the distribution of read-write replicas and a witness replica across zones and regions to keep data durable and writable during failures. The documented eur6 multi-region configuration uses four read-write replicas provisioned equally across two regions and in separate zones, plus a witness replica in a third region. The application writes data to and reads data from the multi-region Spanner instance, and all replicas coordinate to keep the data consistent across regions.
This placement separates failure domains on two levels. Separate zones within each of the two main regions protect against a zonal outage, because surviving read-write replicas in the same region can continue to serve. A third region holding the witness replica protects against a regional outage, because voting and coordination can still succeed even if one of the two main regions is lost.
Exam tip: A regional resource protects against zone loss inside one region, while a multi-regional Spanner instance with replicas in two regions plus a witness in a third protects against full region loss.
RPO and RTO targets in Cloud Spanner define how much data loss and downtime a database design can tolerate. Recovery Point Objective (RPO) is the maximum amount of data that can be lost, where zero RPO means no committed writes are lost, and Recovery Time Objective (RTO) is the time required to restore service, often measured in minutes. Cloud Spanner meets strict RPO and RTO targets as a managed service because Google Cloud manages data replication, backups, and underlying infrastructure under an availability Service Level Agreement (SLA).
Synchronous replication is the mechanism that keeps RPO near zero because a write is durably stored in multiple replicas before it is acknowledged. Regional synchronously replicated storage acknowledges writes only after data persists in both zones, and multi-regional Spanner extends that durability across regions so committed data survives zone and region failures. Because replication, health checking, and failover are built into the managed service, recovery does not depend on manually detecting an outage and force-attaching storage to a standby virtual machine.
A multi-region application stack with Cloud Spanner is a design that distributes every tier across two regions while keeping DNS and the database as shared multi-region resources. Traffic flows from the global DNS routing policy to a regional external Application Load Balancer in each region, then to web servers, then to application servers, and finally to the multi-region Spanner instance for reads and writes. The database tier depends on replicas in multiple regions, while the compute tiers depend on the Spanner instance for consistent reads and writes.
The stack includes the following redundant components:
If one region fails, DNS steers users to the surviving region where load balancers, web servers, and application servers are already running. The application remains responsive because the Spanner instance is still available through its replicas in the surviving regions, so no database restore or cross-region data copy is needed before serving traffic.
Last updated