Overview of the High Availability Configuration

This page describes the high availability configuration for Second Generation instances.

For help with configuring high availability, see Configuring a Second Generation Instance for High Availability.

What the high availability configuration is

A Second Generation instance is in an high availability configuration when it has a failover replica. The failover replica must be in a different zone than the original instance, also called the master. All changes made to the data on the master, including to user tables, are replicated to the failover replica using semisynchronous replication.

What the high availability configuration provides

If the zone where the master is located experiences an outage, Cloud SQL automatically fails over to the failover replica, and your data continues to be available to clients.

This capability is built in for First Generation instances. Cloud SQL Second Generation provides the high availability configuration as an option so you can reduce your costs for non-production instances.

How to configure an instance for high availability

The easiest way to configure a Second Generation instance for high availability is when you create the instance. You can also configure an existing 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.

Requirements for the high availability configuration

The high availability configuration is available only for databases using the InnoDB storage engine.
For more information about InnoDB, see the MySQL documentation.

Failover replicas must be in the same project and region as the master instance.

How configuring an instance for high availability affects your charges

The failover replica is billed as a separate instance.

When failover is triggered

Failover is triggered when the zone where the master is located experiences an outage. If your master instance is experiencing issues not caused by a zone outage, a failover is not initiated.

You can also initiate failover manually. For information, see Initiating failover.

How failover affects your applications and your instances

When a zonal outage occurs and your master fails over to your failover replica, any existing connections to the instance are closed. However, your application can reconnect using the same connection string or IP address; you do not need to update your application after a failover.

After the failover, the replica becomes the master, and Cloud SQL automatically creates a new failover replica in another zone. If you located your Cloud SQL instance to be near other resources, such as a Compute Engine instance, you can relocate your Cloud SQL instance back to its original zone when the zone becomes available. Otherwise, there is no need to relocate your instance after a failover.

About using the failover replica as a read replica

You can use the failover replica as a read replica, to offload read operations from the master.

You can create only one failover replica for every master. You can create additional read replicas to offload read operations from the master.

For more information about creating read replicas, see Configuring Replication.

How the failover replica is configured

The failover replica is configured with the same MySQL flags, users (including root) and passwords, authorized applications and networks, and databases as the master. You cannot change the replica's activation policy or enable backups. Backups must be performed on the master instance.

When replication can be disabled

A master instance falls out of high availability mode when the failover replica becomes unavailable. This can happen, for example, if the network connection between the master instance and failover replica is interrupted, or if the failover replica is down due to its own zone failure. During this time, the master instance is not in high availability mode, and you will not be able to failover to the replica, because it is not safe to do so. The failover replica resumes replication on reconnection, and high availability mode is reenabled when the failover replica finishes catching up.

When you restore a master instance from a backup, replication is disabled. After restoring a master instance from a backup or performing a point-in-time recovery on the master, you should delete and recreate the failover replica.

How you view the health of your high availability configuration

Replica availability

The state of failover replica availability (true or false) is available as a metric of the master:

cloudsql.googleapis.com/database/mysql/replication/available_for_failover

This state is also included in the response of the Get request of the master instance in the failoverReplica.available field.

Replication lag

Pending events are replicated to the failover replica instance as part of semisynchronous replication. A failover operation waits for these pending events on the failover replica to be committed. Consequently, its runtime is dependent on the lag between the failover replica and its master.

The state of replication lag is available as a metric of the replica:

cloudsql.googleapis.com/database/mysql/replication/seconds_behind_master

The value for this metric represents the number of seconds the replica is behind the master.

For information on viewing replication metrics, see Viewing and exporting MySQL error logs.

What's next

Send feedback about...

Cloud SQL Documentation