Cross-region replicas

This page describes how to use cross-region replicas for a Cloud SQL instance.

About cross-region replicas

A read replica is a copy of the primary ("master") that reflects changes to the primary instance in almost real time. You create a replica to offload read requests or analytics traffic from the primary. You can create multiple read replicas for a single primary instance. We recommend a maximum of 5 replicas in total. Read replicas are read-only. You cannot write to them.

Cross-region replication lets you create a read replica in a different region than the primary instance. You create a cross-region read replica the same way as an in-region replica, see Creating read replicas for more information.

Cross-region replicas:

  • Improve read performance by making replicas available closer to your application's region.
  • Provide additional disaster recovery capability to guard against a region failure.
  • Let you migrate data from one region to another with minimum downtime.

Managing cross-region replicas

Once created, you manage cross-region replicas the same way as in-region replicas, as described in Managing replicas. You can do the following:

  • Disable replication

  • Enable replication

  • Promote a replica

  • Check replication status

Monitoring

You can use the monitoring tools to track the general health of your primary and replica instances.

Billing

In addition to the regular cost associated with any Cloud SQL instances, a cross-region replica incurs cross-region network egress charges for replication logs sent from the primary to the replica, as described in Network Egress Pricing.

Pricing for cross-region read replica is the same as creating a new instance in the region. Refer to Cloud SQL instance pricing and select the appropriate region.

Promoting replicas for regional migration or disaster recovery

Overview

There are two common scenarios for promoting replicas: regional migration, and disaster recovery. Both involve setting up cross-region replication and then promoting the replica. The main difference between them is whether the promotion of the replica is:

  • planned (to support a planned migration of a database) or
  • unplanned (because the primary instance becomes unavailable).

Determining Switch-over Criteria

When the primary instance is stopped, you can check the replication lag in the monitoring dashboard to see whether it meets your switch-over criteria.

Check the Replica Lag values (in seconds). When there is a regional outage in the region of the primary instance, the Replica Lag metric for MySQL indicates the data replication lag time for the instance and it should decrease over time.

Promoting a read replica

Once you determine the switch-over criteria are met, you can promote one of the replicas to a writeable, standalone instance. Consider the following scenario:

  • Region A (us-central1) has a High Availability primary instance (db-a-0)
  • Region B (us-west1) has a replica in a different region (db-b-1)
  • Region C (us-east1) also has a replica in a different region (db-c-1)

You could choose to promote db-b-1 in Region B to become a standalone writable instance.

See Promoting a replica for detailed instructions.

Enabling high availability for the promoted instance

Read replicas are not automatically configured as High Availability (HA) instances when they are promoted. You can enable HA after promoting it, as you would with any non-replica instance. See Enabling and disabling high availability for more information.

Recreating additional replicas

If you promote a replica to become a primary instance, you need to create a new replica if you want to replace it. For example, consider the configuration referenced earlier and repeated here:

  • Region A (us-central1) has a High Availability primary instance (db-a-0)
  • Region B (us-west1) has a replica in a different region (db-b-1)
  • Region C (us-east1) also has a replica in a different region (db-c-1)

If the primary instance (db-a-0) becomes unavailable, you can promote the replica in region B to become the primary. To again have additional replicas in regions A and C, delete the old instances (the former primary instance in A, and the replica in C), and create new read replicas from the new primary instance in B.

The resulting configuration would be:

  • Region A (us-central1) now has a replica (db-a-1)
  • Region B (us-west1) now has the primary instance (db-b-1)
  • Region C (us-east1) now has a new replica (db-c-2)