Cloud SQL Regional Failover: Configure Automatic Standby and Verify Recovery

The useful answer

A Cloud SQL instance in a single zone is vulnerable to zone-level outages. If that zone becomes unavailable, your database is unavailable with it. The practical fix is to create the instance with --availability-type=REGIONAL. Google Cloud provisions a synchronous standby in a different zone within the same region. If the primary fails, the standby takes over automatically, typically within 60 to 120 seconds, while the instance IP address and connection name stay the same.

This is not a read replica. Read replicas replicate asynchronously and cannot be promoted automatically. A regional failover replica is for availability, not read scaling.

How the mechanism works

When you set availability type to REGIONAL, Cloud SQL runs a primary instance and a standby instance synchronously. Writes are committed to both before the primary acknowledges them. The standby stays in the same region but a different zone. Cloud SQL monitors instance health and zone reachability. On a zone outage or primary failure, it promotes the standby and updates routing so clients can reconnect to the same endpoint.

Because the IP address is retained, application connection strings do not change. However, existing TCP connections break during failover, so applications need retry logic or connection pooling that can re-establish sessions.

Worked configuration: create, verify, and test

Use the gcloud CLI in Cloud Shell or from a local terminal where the Google Cloud SDK is installed and authenticated. The following example creates a PostgreSQL 14 instance with no public IP, so clients reach it through private connectivity such as a VPC network or Cloud SQL Auth Proxy.

Command context	Detail
Where to run	Cloud Shell or local terminal with gcloud authenticated to the target project
Required permissions	roles/cloudsql.admin, or Project Owner/Editor on the project
Placeholder	INSTANCE_NAME: replace with your Cloud SQL instance ID
Expected check	settings.availabilityType returns REGIONAL after creation
Relevant risk	Forced failover interrupts client connections for roughly 60 to 120 seconds

Create the instance

gcloud sql instances create INSTANCE_NAME --database-version=POSTGRES_14 --tier=db-custom-2-7680 --availability-type=REGIONAL --region=us-central1 --no-assign-ip

Version assumption: this example uses PostgreSQL 14. Regional failover is also supported for MySQL and SQL Server on Enterprise and Enterprise Plus tiers.

Verify the standby is configured

gcloud sql instances describe INSTANCE_NAME --format='value(settings.availabilityType)'

Expect the value REGIONAL. If it returns ZONAL, the instance has no standby and will not fail over automatically.

Test failover manually

Automatic failover happens only during an actual zone outage or health-check failure. To verify recovery behavior before an incident, force a failover:

gcloud sql instances failover INSTANCE_NAME --force

This changes which zone serves the instance. Client connections drop briefly. After the command completes, reconnect using the same instance connection name or IP and confirm that writes succeed. There is no automatic failback; if you want the primary to return to the original zone, initiate another failover, which causes a second brief interruption.

Limits and common mistakes

• Cost: A regional instance costs roughly double the hourly rate of a standalone instance because you are paying for two nodes.
• Tiers: Failover replicas are supported on Enterprise and Enterprise Plus tiers for MySQL, PostgreSQL, and SQL Server. Lower tiers do not offer this availability type.
• Not for read scaling: Do not use a failover replica to offload read queries. Create an asynchronous read replica for that purpose.
• Scope: Automatic failover covers zone-level outages and instance health issues. It does not protect against a regional outage.
• Maintenance windows: Configure a maintenance window so Google Cloud does not apply updates during peak traffic and trigger an unexpected failover.
• Application retries: Because connections drop during failover, applications without retry logic may surface errors until they reconnect.

Practical verification after failover

1. Run the describe command above and confirm settings.availabilityType is still REGIONAL.
2. Reconnect to the instance using the same connection string or private IP.
3. Run a write operation and confirm it commits on the new primary.
4. Check Cloud Monitoring or the instance logs for the failover event and duration.

Rollback and state changes

Forced failover is a state-changing operation. It does not roll back automatically. To return service to the original zone, run gcloud sql instances failover INSTANCE_NAME --force again and accept another brief connection interruption.