Study guide
6.2 Cloud SQL Availability and Recovery
Google Cloud Professional Cloud Developer Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Exam and Compute Platform Decisions
1.1 Current Exam, Sources, and Scenario Method 1.2 Cloud Run Execution and Platform Selection 1.3 GKE Modes and Compute Engine Trade-offs
2 Chapter 2: Container Engineering and API Contracts
2.1 Stateless Microservices and Multi-stage Builds 2.2 Container Hardening, Signals, and Layer Caching 2.3 REST, gRPC, and Protobuf Contracts
3 Chapter 3: gRPC Compatibility and Geographic Routing
3.1 Schema Evolution and gRPC Routing 3.2 Geography, Network Tiers, and Load Balancers 3.3 Serverless NEGs, Sessions, and Edge Controls
4 Chapter 4: API Management and Caching
4.1 API Management & Rate Limiting with Apigee and API Gateway 4.2 Memorystore and Cache Access Patterns 4.3 Cache Invalidation, Capacity, and Failover
5 Chapter 5: Messaging, Task Dispatch, and Orchestration
5.1 Event-Driven Messaging with Cloud Pub/Sub 5.2 Task Queues & Rate Throttling with Cloud Tasks 5.3 Event Routing and Service Orchestration: Eventarc & Cloud Workflows
6 Chapter 6: Resilience and Relational Availability
6.1 Designing Resilient Systems: Circuit Breaking, Retries & Failover 6.2 Cloud SQL Availability and Recovery 6.3 Connection Budgets and Spanner Consistency
7 Chapter 7: Distributed Schemas and NoSQL Data Models
7.1 Spanner Keys, Indexes, and Transactions 7.2 Firestore Data, Indexes, and Transactions 7.3 Bigtable Row Keys and Replication
8 Chapter 8: Object Storage and Application Identity
8.1 Cloud Storage Lifecycle and Signed Access 8.2 Workload Identity and Service Authentication 8.3 Secret Delivery, Rotation, and IAP
9 Chapter 9: Security, Data Integration, and Developer Credentials
9.1 Private Communication, Key Rotation, and Vulnerability Response 9.2 AlloyDB Schemas and BigQuery Ingestion 9.3 CLI Configurations, Local ADC, and Cloud Shell
10 Chapter 10: Managed Development and Automated Tests
10.1 Cloud Workstations and the Container Inner Loop 10.2 Emulating Google Cloud Services & Database Auth Proxies 10.3 Automated Testing Strategies: Unit, Integration, and Mocking
11 Chapter 11: AI Development Tools and Build Pipelines
11.1 AI Coding Assistants, Context, MCP, and Test Review 11.2 Cloud Build Workers and Step Dependencies 11.3 Builders, Substitutions, Triggers, and IAM
12 Chapter 12: Artifact Security and Admission Policies
12.1 Artifact Management and Vulnerability Scanning with Artifact Registry 12.2 Build Provenance and Admission Concepts 12.3 Attestors, Policy Enforcement, and Break-glass
13 Chapter 13: Cloud Run and GKE Deployment Configuration
13.1 Cloud Run Deployment and Scaling Configuration 13.2 Cloud Run CPU, Private Egress, and Secrets 13.3 GKE Workload Controllers and Gateway Routing
14 Chapter 14: Kubernetes Resources, Health, and Progressive Releases
14.1 GKE Resources, OOM Diagnosis, and Autoscaling 14.2 Container Health Probes, Lifecycle Hooks & Graceful Shutdown 14.3 Progressive Delivery: Traffic Splitting, Canary, and Blue/Green Rollouts
15 Chapter 15: Source/Event Deployment and Cloud API Integration
15.1 Source Deployment, Event Receivers, and API Versions 15.2 Client Libraries, Service Enablement, and ADC 15.3 API Responses, Pagination, Caches, and Retries
16 Chapter 16: Tracing, Sampling, and Monitoring
16.1 Trace Context and OpenTelemetry Export 16.2 Custom Spans, Trace Analysis, and Sampling 16.3 Application Metrics, Health Checks & Alerting with Cloud Monitoring
17 Chapter 17: Structured Logs, Routing, and Error Management
17.1 Structured Logs, Trace Correlation, and Queries 17.2 Log Routing, Export Destinations, and Exclusions 17.3 Error Reporting Formats and Regression Handling
18 Chapter 18: Profiling, Generative AI, and Assisted Troubleshooting
18.1 Cloud Profiler Types and Flame Graph Analysis 18.2 Generative AI Integration with the Google Gen AI SDK 18.3 Evidence-Based Troubleshooting with AI Assistance
6.2 Cloud SQL Availability and Recovery
Key Takeaways Explain This Topic AI
Regional HA and cross-region read replicas protect different failure boundaries.
PITR restores into a new instance rather than undoing a deletion in place.
Recovery windows and backup options depend on engine, edition and configuration.
Last updated: October 2026
Relational Storage Patterns: Cloud SQL and Cloud Spanner
Modern cloud-native architectures require developers to select relational storage systems that balance relational semantics, transaction consistency, operational overhead, and scalability. In Google Cloud, relational database workloads primarily target two managed services: Cloud SQL for traditional single-region or replicated relational workloads, and Cloud Spanner for enterprise systems demanding horizontal scaling, multi-region active-active availability, and strictly serializable ACID transactions. The Google Cloud Professional Cloud Developer exam rigorously tests your ability to configure high availability, design anti-hotspotting schemas, manage database connection scaling, and evaluate the trade-offs between Cloud SQL and Cloud Spanner.
The HA and PITR examples below focus on Cloud SQL PostgreSQL; compare the current engine-specific documentation for MySQL or SQL Server.
Cloud SQL: Fully Managed Relational Engines
Cloud SQL delivers fully managed instances of three industry-standard relational database engines:
- PostgreSQL (supported versions depend on edition and lifecycle; check the current version policy)
- MySQL (supported versions depend on the version policy)
- SQL Server (supported versions and editions depend on the current service matrix)
- Core Management Capabilities
Automated Maintenance and Patching: Google Cloud automatically patches the underlying operating system and database engine during configurable weekly maintenance windows. Developers can specify rollout channels ( preview or production ) and set maintenance deny periods of up to 90 days to prevent updates during business-critical sales cycles.
Storage Autoscaling: When enabled, Cloud SQL can increase storage as space becomes low. Capacity cannot be reduced in place. Thresholds, increase rules, and maintenance behavior depend on disk type and edition; monitor storage and set a suitable limit rather than relying on a universal percentage or cooldown.
Data Encryption: Data is encrypted at rest by default, with supported CMEK options. Use the Auth Proxy/connectors or explicitly configured TLS for network connections; a database endpoint does not universally enforce TLS 1.3 by default.
High Availability (HA) & Disaster Recovery in Cloud SQL
Cloud SQL High Availability (HA) provides resilience against zonal infrastructure outages through regional synchronous replication . +--------------------------------------------------------------------------+
- | Cloud SQL High Availability (HA) Regional Configuration |
- +--------------------------------------------------------------------------+
- | Region: us-central1 |
- | |
- | Primary Zone: us-central1-a Standby Zone: us-central1-c |
- | +---------------------------+ +---------------------------+ |
- | | Primary Database Instance | | Standby Instance | |
- | | (Serves Read/Write App) | | (Passive, Pre-warmed VM) | |
- | +-------------+-------------+ +-------------+-------------+ |
- | | | |
- | v v |
- | +-------------+-------------+ +-------------+-------------+ |
- | | Primary Persistent Disk |===========>| Standby Persistent Disk | |
- | | (Active Data Storage) |Synchronous | (Mirrored Storage) | |
- | +---------------------------+Replication +---------------------------+ |
- +--------------------------------------------------------------------------+
- HA Architecture & Failover Mechanics
Topology: An HA instance consists of a primary instance in a primary zone (e.g., us-central1-a ) and a standby instance in a secondary zone within the same region (e.g., us-central1-c ).
Synchronous Block-Level Replication: Storage replication between the primary and standby nodes is handled at the regional persistent disk level. Every committed database transaction must be written synchronously to disks in both zones before being acknowledged to the application client, guaranteeing a Recovery Point Objective (RPO) of 0 (zero data loss).
Failure Detection: Managed health checking determines whether automatic failover is appropriate. Application failure detection, retries, and total recovery time must be measured separately.
Failover Duration: Failover interrupts existing connections; duration varies with configuration and recovery. Do not equate an availability SLA with a guaranteed per-incident RTO. The standby instance attaches the mirrored persistent disk, initializes database engine processes, and assumes the primary instance's static IP and DNS name. Application clients reconnect to the exact same IP address or connection string without manual reconfiguration.
Read Replicas and Read Scaling
Asynchronous Replication: Read replicas replicate asynchronously from the primary instance. Because replication is asynchronous, read replicas experience replication lag and are suitable for read-heavy query offloading, reporting, and dashboard generation, but not for strict read-your-writes consistency.
Cross-Zone vs. Cross-Region Replicas: Read replicas can reside in the same zone, a different zone within the same region, or in an entirely different geographic region. Cross-region read replicas provide localized low-latency reads for global users and serve as disaster recovery standbys that can be manually promoted to a standalone read-write database if a regional disaster occurs.
Replica Promotion: Promoting a read replica converts it into an independent read-write Cloud SQL instance. This breaks the original replication relationship. Re-establishing replication requires a deliberate recovery or migration procedure; it is not an automatic undo.
Backups & Point-In-Time Recovery (PITR)
Capability Automated Backups Point-In-Time Recovery (PITR)
Mechanism Daily scheduled disk snapshots taken during a defined backup window. Engine-specific recovery logs, such as PostgreSQL WAL or MySQL binary logs, together with backups.
Recovery Granularity Restores state to the exact moment the daily snapshot completed. Restores state to a supported timestamp within the retention window.
Retention Period Depends on the standard/enhanced backup option and retention configuration. For Cloud SQL PostgreSQL: 1-7 days in Enterprise, 1-35 days in Enterprise Plus; check engine and backup settings.
Restoration Target Restores into the existing instance (overwriting data) or into a brand-new instance. Must restore into a brand-new Cloud SQL instance ; cannot overwrite in-place.
Primary Use Case Disaster recovery after catastrophic loss; baseline archival. Undoing developer errors (accidental DROP TABLE , bad migration script, data corruption).
Exam Trap: PITR restores data to a new instance , not to the existing instance. When recovering from an accidental table deletion, developers must restore PITR data to a new database instance, extract the dropped tables or records, and re-import them into the production database—or redirect application traffic to the newly restored instance.
Official references checked October 18, 2026: Google Cloud 1 , Google Cloud 2 .