About replication in Cloud SQL

Stay organized with collections Save and categorize content based on your preferences.

Replication is the ability to create copies of a Cloud SQL instance or an on-premises database, and offload work to the copies.

Introduction

The primary reason for using replication is to scale the use of data in a database without degrading performance.

Other reasons include:

  • Migrating data between regions
  • Migrating data between platforms
  • Migrating data from an on-premises database to Cloud SQL

Additionally, a replica could be promoted if the original instance becomes corrupted.

When referring to a Cloud SQL instance, the instance that is replicated is called the primary instance and the copies are called read replicas. The primary instance and read replicas reside in Cloud SQL.

When referring to an on-premises database, the replication scenario is called replicating from an external server. In this scenario, the database that is replicated is the source database server. The copies that reside in Cloud SQL are called Cloud SQL replicas. There is also an instance that represents the source database server in Cloud SQL called the source representation instance.

In a disaster recovery scenario, you can promote a replica to convert it to a primary instance. This way, you can use it in place of an instance that's in a region that's having an outage. You can also promote a replica to replace an instance that's corrupted.

Cloud SQL supports the following types of replicas:

You can also use Database Migration Service for continuous replication from a source database server to Cloud SQL.

Cloud SQL doesn't support replication between two external servers.

Read replicas

You use a read replica to offload work from a Cloud SQL instance. The read replica is an exact copy of the primary instance. Data and other changes on the primary instance are updated in almost real time on the read replica.

Read replicas are read-only; you cannot write to them. The read replica processes queries, read requests, and analytics traffic, thus reducing the load on the primary instance.

You connect to a replica directly using its connection name and IP address. If you're connecting to a replica using a private IP address, you don't need to create an additional VPC private connection for the replica because the connection is inherited from the primary instance.

For information about how to create a read replica, see Creating read replicas. For information about managing a read replica, see Managing read replicas.

As a best practice, put read replicas in a different zone than the primary instance when you use HA on your primary instance. This practice ensures that read replicas continue to operate when the zone that contains the primary instance has an outage. See the Overview of high availability for more information.

Hash index operations using read replicas

Hash index operations don't use write-ahead-logging for PostgresSQL 9.6 (We only have one version under PostgreSQL 10 that's available on Cloud SQL.). This is documented on the yellow caution box on the PostgresSQL release page. This also applies to Cloud SQL read replicas.

Because hash index updates don't propagate to the read replica under PostgresSQL 9.6, they can't be used by the replica. As a workaround, you can either not have read replicas or upgrade to a major PostgresSQL version (10 or above).

Cross-region read replicas

Cross-region replication lets you create a read replica in a different region from the primary instance. You create a cross-region read replica the same way as you create an in-region replica.

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 regional failure.
  • Let you migrate data from one region to another.

See Promoting replicas for regional migration or disaster recovery for more information about cross-region replicas.

Cascading read replicas

Cascading replication lets you create a read replica under another read replica in the same or a different region. Below are some cases for using cascading replicas:

  • Disaster recovery: You can use a cascading hierarchy of read replicas to simulate the topology of your primary instance and its read replicas. During an outage, your selected read replica is promoted to primary and the read replicas under the new primary continue to replicate and are ready for use.
  • Performance improvements: Reduce the burden on the primary instance by offloading replication work to multiple read replicas.
  • Scale Reads: You can have more replicas to share the read load.
  • Cost reduction: You can reduce networking costs by using a single cascading replica with cross-region replication in other regions.

Terminology

  • Cascading replica: A read replica that has its own replica.
  • Levels: You can create levels of replicas in a cascading replica hierarchy. For example, if you add four replicas to an instance, those four replicas are at the same level.
  • Sibling instances: Multiple replicas that replicate from the same primary instance. Siblings are at the same level in the replica hierarchy. A replica can officially have up to nine siblings.
  • Leaf replica: A read replica that does not have any replicas of its own. In a multi-level replication hierarchy, the leaf replica is the last level.
  • Promote: An action that converts a replica, at any level in the hierarchy, into a primary instance. When promoted, the replica's cascading replica hierarchy is retained.

Configure cascading replicas

Cascading replicas let you add read replicas to any existing replicas. You can add up to four levels of replicas, including the primary instance. When you promote the replica at the top of a cascading replica hierarchy, it becomes a primary instance and its cascading replicas continue to replicate.

To plan your configuration, you need to have a goal for what the read replicas intend to do. The next two sections describe the configurations for disaster recovery and multi-region replication.

Disaster recovery

To understand how cascading replicas help you recover quickly during an outage, consider the following replication scenario:

Configuration

Diagram of a cascading replica configuration with the cascading
             replica in a separate region

Outage

Diagram of promotion during an outage

Promotion

Diagram of the new instance with replicas

If you want to use an instance in Region B in a disaster recovery configuration and have:

  • Replicas in the same region attached to the primary instance (Replica A)
  • Replicas in other regions (Cascading Replica) attached to the primary.

You can create read replicas under the cascading replica in Region B.

On the Outage tab, if there's an outage in Region A, the cascading replica is promoted to a primary instance. It already has read replicas underneath it, reducing the recovery time objective (RTO).

On the Promote tab, you see that when a cascading replica is promoted, its replicas are also promoted and continue to replicate under it.

Multi-region replication

Another use case for cascading replicas is to distribute read capacity to a second region in a cost-efficient manner. Cascading replicas C and D can be created that replicate from Replica B. Clients can distribute read queries across replicas B, C, and D to reduce the load on each replica. The cost of cross-region network traffic is incurred only once, from the primary instance to Replica B. Replication from B to C and D uses in-region network transfer, which is free.

You can create a hierarchy of up to four instances using cascading replicas for multi-region replication:

Primary A → Replica B → Replica C and Replica D

Restrictions

  • Cascading replication can't be used with external primary instances or external primary replicas.
  • You can't delete a replica that has replicas under it. To delete the replica, you must start with the leaf replicas and work your way upward through the hierarchy.
  • Circular region dependency isn't supported. To have the replica of a cascading replica in the same region as the primary instance, the cascading replica must also be in the same region.

External read replicas

External read replicas are external MySQL instances that replicate from a Cloud SQL primary instance. For example, a MySQL instance running on Compute Engine is considered an external instance.

External read replicas have the following restrictions:

  • Replicating to a MySQL instance hosted by another cloud platform might not be possible; check the documentation from the other provider. For example, setting the configuration field replicate-ignore-db is required, and cloud providers where this is not allowed are not supported. See Configuring external replicas for other required configuration fields.
  • If replication is interrupted for a few hours, for example by a network or server outage, the replica falls behind the primary. The replica catches up once it reconnects to the primary and starts replicating again. However, if replication is interrupted for longer than Cloud SQL replication logs are preserved (seven backups), you must delete the replica and create a new one.
  • The data flowing from the primary to the external replica is charged as network egress. See the pricing page for network egress pricing for your Cloud SQL instance type.

Replication use cases

The following use cases apply for each type of replication.

Name Primary Replica Benefits and use cases More information
Read replica Cloud SQL instance Cloud SQL instance
  • Additional read capacity
  • Analytics target
Cross-region read replica Cloud SQL instance Cloud SQL instance
  • Additional read capacity
  • Analytics target
  • Additional disaster recovery capability
  • Improve read performance
  • Migrate data between regions
External read replica Cloud SQL instance MySQL instance external to Cloud SQL
  • Reduced latency for external connections
  • Analytics target
  • Migration path to other platforms
Replication from an external server MySQL instance external to Cloud SQL Cloud SQL for MySQL instance
  • Migration path to Cloud SQL
  • Data replication to Google Cloud Platform
  • Analytics target

Prerequisites for creating a read replica

Before you can create a read replica of a primary Cloud SQL instance, the instance must meet the following requirements:

  • Automated backups must be enabled.
  • Binary logging must be enabled which requires point-in-time recovery to be enabled. Learn more about the impact of these logs.
  • At least one backup must have been created after binary logging was enabled.

Additional requirements for the external replica:

  • The MySQL version of the replica must be the same or higher than the MySQL version of the primary instance. Learn more.
  • For security, you must configure SSL/TLS on your primary instance. Learn more.

Impact of enabling binary logging

You must enable point-in-time recovery to enable binary logging on the primary instance to support read replicas. This has the following impacts:

  • Performance overhead

    Cloud SQL uses row-based replication with MySQL flags sync_binlog=1 and innodb_support_xa=true. Therefore, an additional disk fsync is required for each write operation, which reduces performance.

  • Storage overhead

    Storage of the binary logs is charged at the same rate as regular data. The binary logs are automatically truncated to the age of the oldest automated backup. Cloud SQL currently retains the most recent seven automated backups, and all on-demand backups. The size of the binary logs, and therefore the amount charged, depends on the workload. For example, a write-heavy workload consumes more binary log space than a read-heavy workload.

    You can see the size of binary logs by using the SHOW BINARY LOGS MySQL command.

    When backups are taken, the logs are stored in the backup along with the data.

Binary logging on read replicas

  • Binary logging is supported on read replica instances (MySQL 5.7 and 8.0 only). You enable binary logging on a replica with the same API commands as on the primary, using the instance name of the replica instead of the name of the primary instance. Note that the terms enable binary logging and enable point-in-time recovery are interchangeable.

    Binary logging durability on the replica (but not on the primary) instance can be set with the sync_binlog flag, which controls how often the MySQL server synchronizes the binary log to disk.

    Binary logging can be enabled on a replica even when backup is disabled on the primary.

    If a replica that has this value set is promoted to a standalone server, then the setting is reset to the safe value 1 on the standalone server.

Billing

  • A read replica is charged at the same rate as a standard Cloud SQL instance. There is no charge for the data replication.
  • Because a replica always maintains a connection to its primary, the primary instance is never deactivated. This scenario could result in a billing increase for the primary instance. Learn more.
  • For external replicas, the data flowing from the primary to the external replica is charged as network egress. See the pricing page for network egress pricing for your Cloud SQL instance type.
  • 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 a cross-region read replica is the same as for creating a new instance in the region. Refer to Cloud SQL instance pricing and select the appropriate region. Additionally, it incurs cross-region network egress charges for replication logs sent from the primary instance to the replica, as described in the Network Egress Pricing section of the Cloud SQL Billing topic.

Quick reference for Cloud SQL read replicas

Topic Discussion
Backups You cannot configure backups on the replica.
Cores and memory Read replicas can use a different number of cores and amount of memory from those of the primary instance.
Deleting the primary instance Before you can delete a primary instance, you must promote all of its read replicas to stand-alone instances or delete the read replicas.
Deleting the replica When you delete a replica, there is no impact on the status of the primary instance.
Disabling binary logging Before you can disable binary logs on a primary instance, you must promote or delete all of its read replicas.
Failover A primary instance cannot failover to a read replica, and read replicas are unable to failover in any way during an outage.
High availability Read replicas neither provide high availability nor offer it.
Load balancing Cloud SQL does not provide load balancing between replicas. Use connection pooling and distribute queries across replicas.
Maintenance windows Maintenance windows cannot be set on read replicas and they do not share maintenance windows with the primary instance. Maintenance can occur at any time on the read replica. Maintenance occurs on read replicas at a different time than on the primary instance.
Multiple read replicas You can create up to 10 read replicas for a single primary instance.
Parallel replication For information about using parallel replication for performance improvements, see Configuring parallel replication.
Private IP If you're connecting to a replica using a private IP address, you don't need to create an additional VPC private connection for the replica, as it is inherited from the primary instance.
Restoring the primary instance You cannot restore the primary instance of a replica while the replica exists. Before restoring an instance from a backup, or performing a point-in-time recovery on it, you must promote or delete all of its replicas.
Settings The MySQL settings of the primary instance are propagated to the replica, including root password and changes to the user table. CPU and memory changes are not propagated to the replica.
Stopping a replica You cannot stop a replica. You can restart, delete, or disable replication on it, but you cannot stop it as you can a primary instance.
Upgrading a replica Read replicas can experience a disruptive upgrade at any time.
User tables You cannot make changes on the replica. All user changes must be done on the primary instance.

What's next