Requirements and Tips for Configuring Replication

This page provides requirements and best practices for working with read replicas, external replicas, and external masters.

Read replicas

Read replicas are Cloud SQL instances that replicate from a Cloud SQL master instance.

For information about how to configure a read replica, see Creating Read Replicas.

Master instance requirements

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

  • Binary logging must be enabled. Learn more.
  • At least one backup must have been created since binary logging was enabled.
  • For First Generation instances, the length of the master's instance connection name must be 39 characters or less. Learn more.

Information about Cloud SQL replicas

The following facts apply to Cloud SQL replicas:

  • Because a replica always maintains a connection to its master, the master instance is never deactivated, even if it is a First Generation instance with an activation policy of ON_DEMAND. This scenario could result in a billing increase for the master instance. Learn more.
  • The MySQL settings of the master instance are propagated to the replica, including root password and changes to the user table.
  • After the replica is created, you can change its configuration, as long as it meets the replica requirements.
  • You cannot make changes to the user table on the replica. All user changes must be done on the master instance.
  • You cannot configure backups on the replica.
  • You cannot restore the master 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.
  • A read replica is charged at the same rate as a standard Cloud SQL instance. However, there is no charge for the data replication.
  • Before you can delete a master instance, you must promote all of its read replicas to standalone instances or delete the read replicas.
  • Before you can disable binary logs on a master instance, you must promote or delete all of its read replicas.
  • If you restore the master from a backup or perform a point-in-time recovery on it, you should delete and recreate all of its replicas.
  • Replicas are always the same instance type (First Generation or Second Generation) as the master instance.
  • You cannot create a replica of a replica.

External read replicas

External read replicas are external MySQL instances that are replicating from a Cloud SQL master.

For information about how to configure an external read replica configuration, see Configuring External Replicas.

External read replica configuration requirements

Requirements for the master instance:

  • For First Generation instances, the length of the master's instance connection name must be 39 characters or less. Learn more.
  • The master instance must have binary logging enabled. Learn more.

Requirements for the external replica:

The MySQL version of the replica should be the same or higher than the MySQL version of the master instance. Learn more.

Information about the external replica configuration

The following facts apply to the external replica configuration:

  • A MySQL instance running on Google Compute Engine is considered an external instance.
  • The data flowing from the master to the external replica is charged as network egress. See the pricing page for network egress pricing for your Cloud SQL instance type (First Generation or Second Generation).
  • Replicating to a MySQL instance hosted by another cloud platform might not be possible; check the documentation from the other provider.
  • If replication is interrupted for just a few hours, for example by a network or server outage, the replica falls behind the master. The replica should catch up once it reconnects to the master and starts replicating again. However, if replication is interrupted for longer than Cloud SQL replication logs are preserved (7 backups), you must delete the replica and create a new one.
  • For security, you should configure SSL on your master instance. Learn more.

External masters

External masters are MySQL instances that are external to Cloud SQL and serve as masters to a Cloud SQL instance.

For information about how to configure the external master configuration, see Configuring External Masters.

About this configuration

The Cloud SQL external master configuration enables you to create a Cloud SQL First Generation instance that replicates from a master that is external to Cloud SQL (typically, an on-premises MySQL Server installation).

You can use this configuration to replicate your on-prem instance on Google Cloud Platform, or as a way to migrate your data into Cloud SQL.

This configuration requires a Cloud SQL instance, called the internal master instance, which is shown in Cloud SQL as the master for the Cloud SQL replicas. The internal master instance and the external instance together make up the master instance for the Cloud SQL replica.

Diagram of the external master configuration

Data is replicated directly from the external master to the Cloud SQL replicas; the internal master instance is not involved with data replication. Although the internal master instance appears to be a standard Cloud SQL instance, you are not charged for the internal master instance.

External master configuration requirements

  • The internal master instance and the Cloud SQL replicas must be First Generation instances.
  • The external master instance and the Cloud SQL replicas must use the same version of MySQL (5.5 or 5.6).
  • Binary logging must be enabled on the external master. Learn more.
  • The server-id option must be set to a value of 2 or larger. Learn more.
  • If the external master is on a Compute Engine instance, it must have an assigned public IP address.
  • The external master must be accessible to public IP addresses.
  • The dump file you create of the master, which will be used to provide a starting image for the internal master, must conform to the requirements for dump files for Cloud SQL. Learn more.
  • You must configure a replication user account on the external master with the REPLICATION SLAVE privilege.

Best practices for the external master configuration

For increased security and reliability, follow these best practices when you set up and manage your external master configuration:

  • Connections from Cloud SQL replicas to an external master do not come from the IP address of the Cloud SQL instance; they appear as virtual IP addresses. For this reason, you should configure SSL for the connections from Cloud SQL to external masters.

  • You should not use the root user as your replication user. Exposing the root user to a public IP address poses a security risk.

Information about the external master configuration

The following facts apply to the external master configuration:

  • A master instance running on Google Compute Engine is considered an external master.
  • The import of the external master backup is done automatically for each Cloud SQL replica. The bucket location of the backup is specified when you create a replica.
  • The internal master does not store data; backups are not applicable.
  • When you specify certificates and keys for SSL connections, Google does not store the client keys; you must keep them safe.
  • The internal master is configured by using the Cloud SQL API.
  • You manage the replicas of an external master the same way you manage replicas of a Cloud SQL master. Learn more.

Binary logging impact

You must enable the binary log of the master instance to support read replicas. This has the following impacts:

  • Performance overhead

    Google 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

    The storage of binary logs is charged at the same rate as regular data. Cloud SQL retains binary logs from the time when the oldest backup was taken (Cloud SQL currently retains 7 backups). The size of the binary logs, and therefore the amount charged, depends on the workload. For example, a write-heavy workload will consume 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.

  • Instance restart

    When you enable or disable binary logging, the instance is restarted. Existing database connections are lost and must be reestablished.

About the master instance name length restriction

For First Generation instances, the master instance's full connection name (project name:instance name) must have 39 characters or less. This restriction is based on the limit to the MASTER_HOST option of the CHANGE MASTER TO Syntax. The MASTER_HOST value when viewed from a replica (for example, using SHOW SLAVE STATUS) is /cloudsqlreplication/[INSTANCE_CONNECTION_NAME].

You can find the instance connection name in the instance properties in the Google Cloud Platform Console.

What's next

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Cloud SQL for MySQL