GCP Cloud SQL: High Availability, Read Replicas, and Migration

You’ve just lost a primary database zone. Your app is down, customers are screaming, and your on-call phone is melting. If you’re running Cloud SQL without HA, that’s your fault. High Availability isn’t a luxury—it’s the baseline for any production database. But HA alone won’t save you from read storms or migration nightmares. That’s where read replicas and careful migration planning come in. In this article, I’ll show you how to architect Cloud SQL for resilience, scale reads without breaking the bank, and migrate databases with zero downtime. No fluff, just battle-tested patterns from real outages.

High Availability Architecture: How Cloud SQL HA Works

Cloud SQL HA uses a primary instance in one zone and a standby instance in another zone within the same region. Both share the same persistent disk (regional PD) that replicates synchronously across zones. When the primary fails, the standby takes over with no data loss—the same disk, same IP, same connections. Failover is automatic and typically completes within 60 seconds. However, this is not a multi-region setup. If the entire region goes down, you’re still in trouble. For multi-region DR, you need cross-region replicas. Also note: HA doubles your instance cost (you pay for both primary and standby). But for production, it’s non-negotiable. The standby is idle—you can’t use it for reads. That’s what read replicas are for.

gcloud sql instances create my-db \
  --database-version=POSTGRES_15 \
  --region=us-central1 \
  --availability-type=REGIONAL \
  --tier=db-custom-2-7680 \
  --storage-type=SSD \
  --storage-size=100GB \
  --backup-start-time=03:00

Creating and Managing Read Replicas

Read replicas are copies of your primary instance that serve read traffic. They use asynchronous replication, so there’s a small lag (typically <1 second). You can create multiple replicas, each in a different zone or even region. Use them to offload reporting, analytics, or read-heavy workloads. Crucially, you can promote a read replica to a standalone instance—this is how you perform zero-downtime migrations or recover from regional failures. When creating a replica, choose the same machine type as the primary for consistent performance, or a larger one if the replica will serve heavy read traffic. Monitor replication lag with the cloudsql.googleapis.com/database/replication/lag metric. If lag exceeds your tolerance, scale up the replica or reduce write load on the primary.

gcloud sql instances create my-db-replica \
  --master-instance-name=my-db \
  --region=us-central1 \
  --availability-type=ZONAL \
  --tier=db-custom-2-7680 \
  --storage-type=SSD \
  --storage-size=100GB \
  --replica-type=READ_REPLICA

Connection Routing: Directing Traffic to Replicas

Cloud SQL does not automatically route read queries to replicas. You must configure your application to use separate connection strings for reads and writes. A common pattern is to use a proxy like ProxySQL or PgBouncer, or implement read/write splitting in your application code. For example, in a Python app using SQLAlchemy, you can create two engine instances: one for the primary (writes) and one for the replica (reads). Use a decorator or middleware to route SELECT queries to the replica engine. Be careful with transactions—if a read occurs within a write transaction, it must go to the primary to guarantee consistency. Also, ensure your replica can handle the read load; otherwise, it may become a bottleneck.

from sqlalchemy import create_engine
from sqlalchemy.orm import Session

# Primary for writes
primary_engine = create_engine(
    "postgresql+psycopg2://user:pass@/mydb?host=/cloudsql/my-project:us-central1:my-db"
)
# Replica for reads
replica_engine = create_engine(
    "postgresql+psycopg2://user:pass@/mydb?host=/cloudsql/my-project:us-central1:my-db-replica"
)

def get_db(read_only=False):
    if read_only:
        return Session(bind=replica_engine)
    return Session(bind=primary_engine)

# Usage
with get_db(read_only=True) as session:
    users = session.execute("SELECT * FROM users").fetchall()

Zero-Downtime Migration: Promoting a Read Replica

Promoting a read replica turns it into an independent primary instance. This is the cornerstone of zero-downtime migrations—whether you're upgrading the database version, moving to a different machine type, or changing regions. The process: create a read replica of your current primary, let it catch up, then promote it. After promotion, the old primary becomes standalone (it still exists). You then redirect your application to the new primary. The key is to ensure the replica is fully caught up before promotion. Use gcloud sql instances describe to check replicaLag—it should be 0 seconds. Also, plan for a brief connection interruption during DNS or connection string update. Use a load balancer or proxy to minimize downtime.

# Step 1: Verify replica lag is 0
LAG=$(gcloud sql instances describe my-db-replica \
  --format="value(replicaLag)")
echo "Replica lag: $LAG seconds"

# Step 2: Promote the replica
gcloud sql instances promote-replica my-db-replica

# Step 3: Update application connection strings
# (This step is manual or via config management)
echo "Update your app to point to my-db-replica's IP"

Cross-Region Replicas for Disaster Recovery

A cross-region read replica replicates your primary instance to a different GCP region. This is your best defense against regional outages. The replica uses asynchronous replication, so there will be some data loss (RPO) in a disaster—typically seconds to minutes. To minimize RPO, use a higher replication tier and monitor lag. In a disaster, promote the cross-region replica to become the new primary. Then update your application’s connection string to point to the new region. This process can be automated with Cloud Functions or a managed DR orchestration tool. Remember: cross-region replication incurs network egress costs—monitor your bill.

gcloud sql instances create my-db-dr-replica \
  --master-instance-name=my-db \
  --region=europe-west1 \
  --availability-type=ZONAL \
  --tier=db-custom-2-7680 \
  --storage-type=SSD \
  --storage-size=100GB \
  --replica-type=READ_REPLICA

Enterprise Plus: Advanced DR with Switchover and Write Endpoints

Cloud SQL Enterprise Plus edition provides advanced disaster recovery features beyond standard HA. The key capabilities are replica failover and switchover with zero data loss and automatic DNS write endpoints. A write endpoint is a global DNS name that always resolves to the current primary instance's IP. When you perform a switchover (planned role reversal between primary and DR replica) or replica failover (unplanned disaster), the write endpoint automatically updates—no application connection string changes needed. Switchover is planned: the primary stops writes, waits for the DR replica to catch up, then promotes it. This gives zero data loss and sub-second downtime. Replica failover is for disasters: promotes the DR replica immediately with potential seconds of data loss. After failover, the old primary automatically becomes a read replica of the new primary, enabling fallback. Enterprise Plus also offers data cache for faster reads, near-zero downtime maintenance, and a 99.99% SLA (including maintenance). Use Enterprise Plus for any business-critical database where regional DR and zero-downtime maintenance are required. The cost premium over Enterprise is typically 30-50% but eliminates the operational burden of manual DR procedures.

# Create an Enterprise Plus primary with HA
PRIMARY='my-db-enterprise-plus'
DR_REPLICA='my-db-dr-replica'

gcloud sql instances create $PRIMARY \
  --database-version=POSTGRES_16 \
  --region=us-central1 \
  --availability-type=REGIONAL \
  --tier=db-custom-4-15360 \
  --edition=enterprise-plus \
  --enable-point-in-time-recovery \
  --storage-size=100GB \
  --storage-type=SSD

# Create cross-region DR replica
gcloud sql instances create $DR_REPLICA \
  --master-instance-name=$PRIMARY \
  --region=europe-west1 \
  --availability-type=REGIONAL \
  --tier=db-custom-4-15360 \
  --edition=enterprise-plus \
  --replica-type=READ_REPLICA \
  --enable-point-in-time-recovery

# Designate as DR replica
gcloud sql instances patch $PRIMARY \
  --dr-replica-name=$DR_REPLICA \
  --dr-replica-region=europe-west1

# Perform a switchover (planned)
gcloud sql instances switchover $DR_REPLICA

Maintenance Controls: Near-Zero Downtime Operations

Cloud SQL Enterprise Plus provides advanced maintenance controls that minimize downtime. Key features: near-zero downtime maintenance (sub-second failover during patching), configurable maintenance windows, maintenance notifications (email 1+ week in advance), reschedule maintenance capability, and deny maintenance periods (postpone up to 90 days for sensitive periods like Black Friday). Best practices: configure a maintenance window during off-peak hours, apply maintenance to read replicas before the primary to validate, and enable maintenance notifications. For multi-replica setups, use a rolling maintenance strategy: patch one replica, then the next, then the primary last. Always test maintenance in a staging environment at least a week before production. In production, we use the deny maintenance period to block maintenance during month-end processing and promotional events.

# Configure maintenance window (off-peak)
gcloud sql instances patch my-db \
  --maintenance-window-day=SUNDAY \
  --maintenance-window-hour=3

# Set deny maintenance period (e.g., Black Friday week)
gcloud sql instances patch my-db \
  --deny-maintenance-period-start-date=2026-11-25 \
  --deny-maintenance-period-end-date=2026-11-29

# Reschedule upcoming maintenance
gcloud sql instances reschedule-maintenance my-db \
  --reschedule-type=RESCHEDULE \
  --schedule-time=2026-07-20T03:00:00Z

Migration Strategies: From On-Prem or Other Clouds

Migrating to Cloud SQL from an external database requires careful planning. The recommended approach is to use Database Migration Service (DMS) for continuous replication with minimal downtime. DMS supports MySQL, PostgreSQL, and SQL Server. It creates a Cloud SQL instance and sets up replication from your source. Once replication is caught up, you promote the Cloud SQL instance and cut over. For smaller databases (< 100 GB), you can also use pg_dump/pg_restore or mysqldump, but this requires downtime. Always test the migration in a staging environment first. Pay attention to character sets, time zones, and stored procedures—they may differ between environments.

# Step 1: Create a migration job in DMS (via Console or gcloud)
# Step 2: Start continuous replication
# Step 3: Monitor replication lag
# Step 4: Promote when ready

# Example using gcloud (simplified)
gcloud database-migration migration-jobs create my-migration \
  --source=on-prem \
  --destination=cloud-sql \
  --type=CONTINUOUS \
  --region=us-central1

Monitoring and Alerting for HA and Replicas

Without proper monitoring, your HA setup is a false sense of security. Key metrics to track: replication lag (for replicas), failover events, disk usage, and CPU/memory utilization. Set up Cloud Monitoring dashboards and alerts. For replication lag, alert if it exceeds 10 seconds (or your business tolerance). For HA, monitor the cloudsql.googleapis.com/database/failover metric—it should be 0. If it increments, investigate immediately. Also monitor the standby instance's health—though it's idle, its disk must be healthy. Use uptime checks to verify your database endpoints are reachable. Finally, test failover manually at least once per quarter to ensure it works.

gcloud alpha monitoring policies create \
  --display-name="Cloud SQL Replica Lag Alert" \
  --condition-display-name="Replica lag > 10s" \
  --condition-filter='metric.type="cloudsql.googleapis.com/database/replication/lag" AND resource.type="cloudsql_database"' \
  --condition-threshold-value=10 \
  --condition-threshold-duration=60s \
  --notification-channels="projects/my-project/notificationChannels/12345"

Cost Optimization: Balancing HA, Replicas, and Performance

Cloud SQL costs can spiral if you over-provision. HA doubles your compute cost (you pay for standby). Each read replica adds its own compute and storage cost. To optimize: use smaller machine types for replicas if they handle light read traffic. Consider using committed use discounts (1 or 3 years) for predictable workloads. For development/staging, use zonal (non-HA) instances. Also, right-size your storage—Cloud SQL bills for provisioned storage, not used. Monitor storage utilization and downsize if needed. Finally, use private IP to avoid egress costs between your application and database in the same VPC.

# Estimate monthly cost for HA + 2 replicas
# Primary: db-custom-2-7680 HA = ~$200/month
# Standby: same cost = ~$200/month (included in HA? No, you pay for both)
# Replica 1: db-custom-2-7680 zonal = ~$100/month
# Replica 2: db-custom-2-7680 zonal = ~$100/month
# Storage: 100GB SSD = ~$17/month each = $68/month
# Total ~$668/month
# Without HA: $100 + $100 + $100 + $51 = $351/month
# HA premium: ~$317/month for zone resilience

Common Pitfalls and How to Avoid Them

Pitfall 1: Not testing failover. Many teams assume HA works until it doesn't. Test quarterly. Pitfall 2: Ignoring replication lag. If your app reads from replicas, stale data can cause bugs. Set alerts. Pitfall 3: Using HA for non-critical databases. HA doubles cost—use it only where downtime is unacceptable. Pitfall 4: Overloading a single replica. Distribute read traffic across multiple replicas or use a connection pooler. Pitfall 5: Not planning for regional disasters. HA is zonal; for regional DR, use cross-region replicas. Pitfall 6: Forgetting to update connection strings after promotion. Automate DNS updates or use a proxy that can be reconfigured without code changes.

# Simulate a failover by stopping the primary
PRIMARY=$(gcloud sql instances describe my-db --format="value(gceZone)")
echo "Primary zone: $PRIMARY"

# Stop the primary (simulate failure)
gcloud sql instances patch my-db --activation-policy=NEVER --quiet

# Wait for failover
sleep 120

# Check new primary zone
NEW_PRIMARY=$(gcloud sql instances describe my-db --format="value(gceZone)")
echo "New primary zone: $NEW_PRIMARY"

# Restart the old primary (now a standby)
gcloud sql instances patch my-db --activation-policy=ALWAYS --quiet

Automating HA and Replica Management with Infrastructure as Code

Manual database management is error-prone. Use Terraform or Deployment Manager to define your Cloud SQL instances, replicas, and HA settings as code. This ensures consistency across environments and makes disaster recovery reproducible. For example, a Terraform module can create a primary with HA, a cross-region replica, and monitoring alerts. Store state in a remote backend (e.g., GCS) with locking. Use CI/CD to apply changes after review. Also, consider using Config Connector for Kubernetes-native management if you run on GKE.

resource "google_sql_database_instance" "primary" {
  name             = "my-db"
  database_version = "POSTGRES_15"
  region           = "us-central1"

  settings {
    tier              = "db-custom-2-7680"
    availability_type = "REGIONAL"
    disk_size         = 100
    disk_type         = "PD_SSD"
    backup_configuration {
      enabled                        = true
      start_time                     = "03:00"
      point_in_time_recovery_enabled = true
    }
  }
}

resource "google_sql_database_instance" "replica" {
  name                 = "my-db-replica"
  master_instance_name = google_sql_database_instance.primary.name
  region               = "us-central1"
  database_version     = "POSTGRES_15"

  settings {
    tier              = "db-custom-2-7680"
    availability_type = "ZONAL"
    disk_size         = 100
    disk_type         = "PD_SSD"
  }
}