Overview of the High Availability Configuration

This page describes the high availability configuration for PostgreSQL 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, undergoing maintenance, or performing a long-running operation).

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.

What's next

Was this page helpful? Let us know how we did:

Send feedback about...

Cloud SQL for PostgreSQL