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
Evaluating tradeoffs between zonal, regional, and multi-regional database deployments is the comparison of how well each design survives zone and region failures. The comparison uses Recovery Time Objective (RTO), the time until the system runs again, and Recovery Point Objective (RPO), the amount of committed data that can be lost. In Google Cloud, RTO and RPO are defined by the scope of loss, meaning a zone outage, a region outage, or a multi-region outage. Wider distribution places copies of data and compute on different sides of those failure boundaries, which directly improves RTO and RPO.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) turn business needs into choices about deployment scope. RTO measures downtime after a disaster recovery (opens in a new tab) event, while RPO measures how much committed data can be lost. Business-critical operations that need strict RTO and RPO can depend only on data plane components that continuously process operations. If a critical operation needs the management plane during an outage, such as a virtual machine creation API or an identity permission update, recovery stalls even when the data is still intact.
A zonal deployment hosts resources inside a single zone, so an interruption in that zone can affect all resources in that zone. Compute Engine virtual machines and Persistent Disk are the main zonal resources, with a platform availability target of 99.9% and an RTO of hours or days after a zone outage. A zone outage does not always make every resource unavailable, but the zone defines the expected boundary of the incident and recovery requires waiting for resolution or restoring elsewhere. Correlated outages across multiple zones in one region (opens in a new tab) can still occur, at which point regional outage planning applies.
Surviving a zone failure with zonal resources requires a team to design, build, and test its own failover between zones (opens in a new tab). Traffic flows from Cloud Load Balancing health checks to virtual machines in another zone when the primary zone is judged unhealthy. Capacity flows from Compute Engine instance templates and managed instance groups that run identical virtual machines in multiple zones. Writes flow from a zonal disk to a regional Persistent Disk that synchronously replicates data to another zone in the same region, which is an example of zonal redundancy (opens in a new tab) planning.
A regional deployment redundantly deploys resources across multiple zones in one region, so the resource automatically serves from another zone if one zone is interrupted. Cloud SQL configured for high availability, regional managed instance groups, regional Cloud Storage buckets, and regional Spanner instances are examples of regional resources with a platform availability target of 99.99%. That target still allows nearly an hour of downtime per year, so critical applications need a multi-region disaster recovery plan even when they use regional resources. A failure in one zone is unlikely to affect other zones, and RTO is near zero when data is replicated synchronously between primary and standby copies.
Regional protection stops at the region boundary, so a regional outage affecting more than one zone makes a purely regional database unavailable. Recovery then depends on a passive replica in a different region that is activated during the outage, with RTO and RPO determined by how current that replica is. A Cloud SQL primary in one region can stream to a cross-region read replica using asynchronous replication, and that replica can be promoted to become the new primary after the disaster. Because cross-region replicas can be configured for high availability in advance, the promoted instance does not need additional changes to regain zone resilience, and cascading replicas can provide immediate protection after promotion.
A multi-regional deployment distributes resources within and across regions, so service continues from surviving regions when an entire region fails. Spanner multi-region instances, dual-region and multi-region Cloud Storage buckets, multi-cluster Bigtable instances, and Firestore multi-region locations are examples of multi-regional resources with a platform availability target of 99.999%. RTO is near zero when replication is synchronous, and a globally distributed stack provides the highest robustness against region outages. The tradeoff is between latency, consistency, and cost, with synchronous replication protecting RPO at the cost of higher write latency and asynchronous replication lowering latency at the cost of risking data loss.
Multi-regional behavior depends on the product, so the capability must be checked rather than assumed. Firestore in a multi-region location runs in a multi-zone and multi-region replicated configuration that can withstand loss of entire regions without data loss, while Firestore in a regional location runs only in a multi-zone configuration. Bigtable production instances maintain at least two clusters in unique zones with Google-managed replication, so traffic can fail over to another cluster in the same instance. Spanner regional configurations maintain three read-write replicas in different zones, each holding a full copy that can serve reads and writes, while Spanner multi-region configurations add two read-write regions plus a witness region holding a witness replica.
Latency, replication mode, and consistency tradeoffs explain why replica placement controls both speed and data loss. Zonal resources operate within a single zone, so writes complete without cross-zone network waits. Regional resources add a cross-zone round trip to each write because every synchronous confirmation must travel from the primary to each replica and back. Multi-regional resources add much larger delays when writes are confirmed across continents, which forces a choice between strong consistency and low latency.
Synchronous replication is a write pattern in which the primary waits for replica confirmation before reporting a transaction as committed. Regional Persistent Disk, Hyperdisk Balanced High Availability, AlloyDB Omni in-region replicas, and Cloud SQL high availability all use synchronous replication inside a region to provide RPO=0 for committed data. Asynchronous replication is a write pattern in which the primary commits before replicas confirm, so writes stay fast but recent changes may not yet exist elsewhere. AlloyDB Omni to a remote disaster recovery region, Cloud SQL cross-region read replicas, and Microsoft SQL Server (opens in a new tab) multi-regional designs use asynchronous replication across regions, which creates replication lag and possible data loss during a regional outage.
The following table summarizes platform targets and robustness when replication is synchronous, which is the condition for near-zero RTO.
| Strategy | Availability target | Zone outage robustness | Region outage robustness |
|---|---|---|---|
| Zonal | 99.9% | RTO of hours or days, manual restore or failover to another zone | RTO of hours or days, restore in another region from backup |
| Regional | 99.99% | Near-zero RTO with synchronous replication, automatic failover to standby zone | RTO of hours or days, activate passive replica in another region |
| Multi-regional | 99.999% | Near-zero RTO with synchronous replication, serve from surviving zones | Near-zero RTO with synchronous replication, serve from surviving regions |
Exam tip: Regional deployment protects against zone outages but not region outages, and BigQuery multi-region does not provide cross-region replication because data is stored in a single region within the location.
Cost, residency, and deployment scope connect redundant copies and networks to legal limits on where data can live. Cost and complexity rise with distribution because more resources are provisioned, more data is stored and replicated, and more cross-location traffic flows between sources and destinations. Zonal is low cost and simpler to operate, regional is medium cost and more complex than zonal, and multi-regional is high cost and more complex than regional due to redundant storage and cross-region transfer. Firestore shows the tradeoff directly: regional instances synchronously replicate across at least three zones with lower cost and lower write latency, while multi-regional instances synchronously replicate across five zones in three regions with two serving regions and one witness region.
Data residency defines which regions are allowed to store and serve a copy of the data. Regional storage survives zonal failure without leaving the chosen region and does not fail over to another region. Document AI stores documents regionally with synchronous writes and routes traffic to other zones after a zonal failure but never replicates across regions. Eventarc commits trigger metadata to a quorum within a region and moves requests from unavailable zones to available zones, but customer traffic is never routed to a different region. Choose zonal when downtime of hours or days is acceptable, choose regional when zone failures must be absorbed automatically but activation of a cross-region replica is acceptable, and choose multi-regional when both zone and region failures must be absorbed with near-zero RTO and minimal RPO.
Defining maintenance windows and notifications based on application availability requirements is the practice of timing database upkeep and alerts to protect service level objectives. A maintenance signal flows from the database instance or cluster to a notification workflow, and the workflow flows onward to stakeholders and to application controls. Those controls can shift traffic, pause writes, or hold health checks so planned work does not become an outage.
Availability architectures in AlloyDB Omni define which failures the database can survive and what notifications must cover. Standard Availability uses backups for basic protection, Enhanced Availability adds zonal replication inside a region, and Premium Availability adds zonal plus regional replication for mission-critical needs. The notification plan depends on this choice because a zone or regional event needs stakeholder and application response only when the architecture does not absorb it automatically.
| Architecture | VM and node failure | Zone failure | Regional failure |
|---|---|---|---|
| Standard Availability | Supported | Not supported | Not supported |
| Enhanced Availability | Supported | Supported | Not supported |
| Premium Availability | Supported | Supported | Supported |
Choose Standard Availability when the workload is development or can restore from backup. Choose Enhanced Availability when the workload must survive a zone loss in one region. Choose Premium Availability when the workload must survive a full region loss with 99.99% availability and zero data loss on recovery.
Preparing instances for smooth maintenance means giving Cloud SQL enough space and headroom so routine work does not stall. The instance should keep at least 20% available space to accommodate critical maintenance, keep table count under 10,000 tables per instance to limit upgrade time, and be sized to account for transaction and binary log retention on high-write instances. Without this headroom, maintenance may stall and force a reschedule, so notifications can then focus on expected behavior rather than unexpected capacity failures.
SQL Server workloads have additional storage and growth dependencies that affect maintenance success:
autogrow in megabytes rather than as a percentage, using increments matched to the requirement and managing growth before the threshold is reached.Maintenance windows are scheduled periods that align disruptive upkeep with low-traffic periods for the application. Scheduling depends on application traffic patterns and on recent changes from normal activity, such as adding a new column or a surge of updates on a table. In Cloud SQL, upkeep includes peer tasks that address fragmentation and stale statistics, while track selection balances system stability with adoption of new features.
The core upkeep tasks to schedule during a window are:
For Cloud SQL for SQL Server, upkeep also includes monitoring for missing indexes. When a performance issue is active, vertically scale first and reschedule deeper tuning, query rewrites, partitioning, or sharding until after the incident.
Maintenance mode (opens in a new tab) for AlloyDB Omni in Kubernetes is a state that keeps a database pod in a running state while repair or update work proceeds. Maintenance mode applies only to AlloyDB Omni using the container orchestrator deployment option and does not apply to AlloyDB Omni using containers. It works by disabling the liveness probes and startup probes on the database container that Kubernetes uses to check pod health, so Kubernetes does not restart the pod for failed health checks.
The enable sequence states its order explicitly. First, verify that probes exist by inspecting the pod specification in its namespace for the database container liveness probe and startup probe, using kubectl get po with the namespace and database pod name. Then, disable the liveness and startup probes to place the pod in maintenance mode. Only after the work is complete, re-enable the probes so health reporting flows again from the database container to Kubernetes. Application readiness protocols should treat the maintenance-mode pod as intentionally unavailable for new work until probes are restored.
Rescheduling rules and incident response order prevent maintenance and scaling actions from harming availability during peak demand. Recurring upkeep should be moved to periods when it will not harm availability, and disruptive changes should be excluded from critical business periods. If an instance is scaled down more than once during a three-hour period, only the first scale down event benefits from near-zero downtime and subsequent scale down events experience regular downtime. Postpone a second scale down until after the three-hour window when availability matters.
Incident response is an ordered escalation where low-effort actions are tried before disruptive re-architecture. Notifications flow alongside this sequence from the database operations team to stakeholders through Cloud Pub/Sub or email alerts. The alerts mark when maintenance starts, when traffic shifts to a replica, and when the system returns to normal, so applications can shed load, retry safely, or fail over in step with the database.
Exam tip: Maintenance mode disables liveness and startup probes to prevent restarts during repair; it does not remove the need for 20% free space and under 10,000 tables for a smooth upgrade.
Last updated