This page describes the high availability configuration for Cloud SQL instances. The high availability configuration, sometimes called a cluster, provides failover capability.
For help with configuring high availability, see Configuring an Instance for High Availability.
What the high availability configuration is
A Cloud SQL instance configured for high availability is also called a regional instance. A regional instance is located in two zones within the configured region, so if it cannot serve data from its primary zone, it fails over and continues to serve data from its secondary zone.
For more information about zones and regions, see Instance Locations.
What the high availability configuration provides
If an instance configured for high availability experiences an outage or becomes unresponsive, Cloud SQL automatically switches to serving data from the secondary zone. This is called a failover.
How to configure an instance for high availability
You can configure an instance for high availability when you create it, or convert an existing stand-alone instance for high availability. For more information, see Configuring an Instance for High Availability.
Which instances should be configured for high availability
You should configure all of your instances that contain production data for high availability.
How configuring an instance for high availability affects your charges
The instance charges for an instance configured for high availability are charged at double the price of a stand-alone instance. This includes CPU, RAM, and storage. For more information, see the pricing page.
When failover is triggered
Failover is triggered when one of the following scenarios occur:
- The zone where the regional instance is located experiences an outage.
- The regional instance is unresponsive for approximately 60 seconds.
The instance must be in a normal operating state (not stopped or undergoing maintenance).
You can also initiate failover manually. For information, see Initiating failover.
How failover affects your applications and your instances
When a failover is initiated, any existing connections to the instance are closed. You do not need to update your application after a failover; it connects to the instance with the same connection parameters used before the failover. The application is responsible for reconnecting to the database, preferably using exponential backoff.
After the failover, the instance resumes serving data, from its secondary zone. You can see the zone your instance is serving data from by going to its Overview page in the GCP Console.
You should initiate a failover in a test environment to see exactly how your applications are affected.
How the high availability configuration affects backups and restores
Configuring an instance for high availability does not affect your need for backups, nor does it change how you create backups or restore an instance.
How the high availability configuration differs between MySQL and PostgreSQL
There are some differences in the high availability configuration between MySQL and PostgreSQL instances that impact how you work with highly-available instances:
Highly-available PostgreSQL instances do not have a separate failover instance the way MySQL instances do.
This has the following consequences:
There is no concept of replication lag, as there is for MySQL instances. As long as the secondary zone is healthy, failover can occur.
If you need to offload read operations, you must create a read replica.
If a failover occurs, read replicas replicating from a PostgreSQL regional instance do not change zones; they continue to serve data, even if they are now in a different zone than the primary instance. You can initiate another failover, in this case called a failback, to return the regional instance to serving data from its original zone.
Enabling automatic backups is not required for highly-available PostgreSQL instances, as it is for MySQL. However, enabling automatic backups is recommended for increased data durability.
- Configure high availability for a new or existing instance.
- Learn more about managing your database connections.
- Test how your application responds to lost connections by restarting your instance.
- Learn more about regions and zones in Cloud SQL.