For information about how to configure a read replica, see Creating read replicas.
Read replicas are Cloud SQL instances that replicate from a Cloud SQL primary instance. Read replicas are read-only. You cannot write to them. You can use a replica to offload read requests and analytics traffic from the primary instance.
For information about how to configure a read replica, see Creating Read Replicas.
Read replica primary instance requirements
Before you can create a 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 after binary logging was enabled.
Quick reference for Cloud SQL read replica topics
|High availability||Read replicas neither provide high availability nor offer it.|
|Failover||A primary instance cannot failover to a read replica, and read replicas are unable to failover in any way during an outage.|
|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.|
|Disruptive upgrades||Read replicas can experience a disruptive upgrade at any time.|
|Performance||When you create a read replica, it does not impact the performance or availability of the primary instance.|
|Multiple read replicas||You can create multiple read replicas for a single primary instance.|
|Load balancing||Cloud SQL does not provide load balancing between replicas.|
|Settings||The MySQL settings of the primary instance are propagated to the replica, including root password and changes to the user table. Tier changes are not propagated to the replica.|
|Machine types||Read replicas can be a different machine type (or tier) than the primary instance. Read replicas can have more CPUs and memory than the primary instance, but they cannot have less.|
|User tables||You cannot make changes to the user table on the replica. All user changes must be done on the primary instance.|
|Backups||You cannot configure backups on the replica.|
|Restoring the primary instance||You cannot restore the primary 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.|
|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.|
|Disabling binary logging||Before you can disable binary logs on a primary instance, you must promote or delete all of its read replicas.|
|Creating a replica of a replica||You cannot create a replica of a replica.|
|Stopping a replica||You cannot
- 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.
External read replicas
External read replicas are external MySQL instances that are replicating from a Cloud SQL primary.
For information about how to configure an external read replica configuration, see Configuring External Replicas.
External read replica configuration requirements
Requirements for the primary instance:
The primary 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 primary instance. Learn more.
Information about the external replica configuration
The following facts apply to the external replica configuration:
- A MySQL instance running on Compute Engine is considered an external instance.
- 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.
- 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 primary. The replica should catch 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 (7 backups), you must delete the replica and create a new one.
- For security, you should configure SSL/TLS on your primary instance. Learn more.
Binary logging impact
You must enable the binary log of the primary instance to support read replicas. This has the following impacts:
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 the most recent seven automated, 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 logs are automatically truncated to the age of the oldest automatic backup.
When you enable or disable binary logging, the instance is restarted. Existing database connections are lost and must be reestablished.