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.
Read replica 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.
Information about Cloud SQL read replicas
- Read replicas do not provide high availability; for that, you must configure your master instance for high availability.
- Read replicas do not support the maintenance window setting; they can experience a disruptive upgrade at any time.
- Read replicas are not highly available. If they are located in a zone that experiences a general outage, they go offline.
- The MySQL settings of the master instance are propagated to the replica, including root password and changes to the user table.
- Read replicas can be a different machine type (or tier) than the master instance.
- Replicas are always the same generation (First Generation or Second Generation) as the master instance.
- 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.
- Before you can delete a master instance, you must promote all of its read replicas to stand-alone 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.
- You cannot create a replica of a replica.
- 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 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.
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:
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 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.
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.
server-idoption 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
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 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:
Google Cloud SQL uses row-based replication with MySQL flags
innodb_support_xa=true. Therefore, an additional disk fsync is required for each write operation, which reduces performance.
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.
When you enable or disable binary logging, the instance is restarted. Existing database connections are lost and must be reestablished.