Read replicas are Cloud SQL instances that replicate from a Cloud SQL master instance. Read replicas are read-only. You cannot write to them. You create a replica to offload read requests or analytics traffic from the master.
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.
- You cannot change the tier of the master if doing so would cause it to be larger than any of its replicas.
Information about Cloud SQL read replicas
Read replicas neither provide high availability nor offer it; a master instance cannot fail over to a read replica, and read replicas are unable to fail over in any way during an outage.
Read replicas do not support the maintenance window setting; they can experience a disruptive upgrade at any time.
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.
- When you create a read replica, it does not impact the performance or availability of the master instance.
- You can create multiple read replicas for a single master instance. Cloud SQL does not provide load balancing between replicas.
- The MySQL settings of the master instance are propagated to the replica, including root password and changes to the user table. Tier changes are not propagated to the replica.
- 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.
- Read replicas must be in the same region 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 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/TLS on your master instance. Learn more.
Binary logging impact
You must enable the binary log of the master 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.
- Learn about the external master configuration for Second Generation instances.
- Learn how to create a read replica.
- Learn how to configure an external replica configuration.
- Learn how to configure an external master configuration.
- Learn how to manage replicas.