A Cloud SQL read replica is a copy of a primary instance that exists to serve read operations so the primary does not get overwhelmed by read traffic. Reads are directed to the replica while the primary continues to handle writes, which improves the availability and scalability of the database. The Professional Cloud Database Engineer exam tends to probe the boundaries of what a replica does, because several Cloud SQL features overlap in ways that look similar until you separate them. Read replicas, cross-region read replicas, promotion, and the advanced disaster recovery workflow all relate to each other, and the questions usually come down to telling them apart.
When you add a read replica, the primary instance asynchronously replicates its data to the replica. The application sends its read queries to the replica and its writes to the primary. By moving read traffic off the primary, you free the primary to focus on writes and you add capacity for read-heavy workloads. This is the main reason to use replication, which is to scale the use of data in a database without degrading performance.
Because replication is asynchronous, there can be a slight delay before a change written to the primary is reflected on the replica. This replication lag matters when an application expects to read its own writes immediately. It is a property of the asynchronous design rather than a defect, and it is worth keeping in mind when deciding whether a particular read can tolerate slightly stale data.
Cloud SQL supports several kinds of replicas. Beyond a standard read replica there are cross-region read replicas, cascading read replicas, external read replicas, and Cloud SQL replicas that replicate from an external server. Replication is also used for purposes other than scaling reads, including migrating data between regions, migrating data between platforms, and migrating data from an on-premises database into Cloud SQL.
A cross-region read replica places a copy of the data in a different region from the primary. This serves two purposes. The first is read performance, because hosting the data closer to application users in another region reduces the distance read queries travel. The second is disaster recovery, because a copy of the data already exists in a separate region if the primary region experiences a regional failure.
This is a useful distinction to hold against Cloud SQL high availability. High availability provides automatic failover within a single region by keeping a standby in a second zone, and it does not add read capacity. A cross-region read replica spans regions, does add read capacity, and gives you a recovery option for a full regional outage. When a scenario describes protecting against the loss of an entire region, a cross-region replica is the relevant piece, where a same-region standby would not be.
Promotion is the manual path for turning a replica into a standalone database. Promoting a read replica stops the replication process and converts the replica into an independent primary instance with full read and write capability. This supports disaster recovery if the primary region becomes unavailable for any reason, and it also covers the case where the original primary instance becomes corrupted and a replica needs to take over.
The important operational detail is that promotion requires updating the connection endpoints in your application so that all operations are directed to the new primary. After a promotion there is no link back to the original instance. If you started with a primary in Region A and a cross-region read replica in Region B, a promotion marks the Region A instance as failed or offline and transforms the Region B replica into a new, independent primary. The two are no longer connected, and the Region B instance now acts as a standalone database.
For more structured failover, Cloud SQL offers an advanced disaster recovery configuration available on the Cloud SQL Enterprise Plus edition. This setup lets you designate specific cross-region read replicas as disaster recovery replicas. Rather than a one-way promotion, it manages the relationship between the two instances for you.
The replica failover operation promotes the designated DR replica to be the new primary instance, and the original primary is automatically reconfigured as a replica. You do not have to rebuild the replication relationship by hand. So if Region A was primary and Region B was the DR replica, a replica failover makes Region B the primary and begins replication back to Region A, which is now demoted to a replica.
The switchover operation restores the original configuration with zero data loss. It flips the roles back so that Region A becomes the primary again and replication flows to the replica in Region B. Because switchover is a planned, lossless operation, it can be used to test cross-regional failover in advance of an actual disaster rather than waiting to find out during one. The switchover is run from the command line.
gcloud sql instances switchover REPLICA_IDFor the exam, it helps to keep these apart. A read replica offloads reads and tolerates some lag. A cross-region replica adds read performance in another region and a recovery option for a regional outage. Promotion is a manual, one-way conversion of a replica into an independent primary that requires updating endpoints. The advanced disaster recovery workflow on Enterprise Plus adds managed replica failover and a lossless switchover that can be tested ahead of time. We would generally reach for the advanced workflow when planned, reversible regional failover and rehearsal matter, and a plain promotion when a replica simply needs to become a new standalone primary.
Our Professional Cloud Database Engineer course covers Cloud SQL read replicas alongside high availability and cross-region disaster recovery, with practice questions that drill these distinctions.
