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
The state of failover replica availability (true or false) is available as a metric of the master:
This state is also included in the response of the
Get request of the master
instance in the
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:
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.
- 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 Google Cloud SQL.