AlloyDB cross-region replication keeps a copy of your database in a second region so that the database can survive the loss of an entire region. High availability already protects an AlloyDB instance against a single zonal failure within one region, but it does not help if the whole region goes offline. Cross-region replication fills that gap. The Professional Cloud Database Engineer exam tends to test where the line between those two mechanisms sits, so it is worth being precise about what cross-region replication does and what it is for.
The setup starts with a primary cluster in one region, which we can call Region A. The primary cluster holds the read-write workload, with a primary instance that handles writes and read pool instances that serve read traffic locally. Data from the primary cluster is then synchronized into a secondary cluster in a second region, Region B, using asynchronous replication.
The secondary cluster is read-only while the primary is healthy. Because replication is asynchronous, the secondary stays updated as a read-only copy without adding high network latency to the primary region. If replication were synchronous, every write would have to wait for the remote region to acknowledge it, which would slow down the primary. Keeping it asynchronous means the write performance of the primary region is not held back by the distance to the secondary.
The main reason to run a secondary cluster is disaster recovery. If the primary region fails, the secondary cluster can be promoted to become the primary. Once promoted, it becomes the new read-write hub for the entire application, so the database stays operational even during a total regional outage. This is the same idea as promoting a Cloud SQL cross-region read replica, where a read replica can be promoted to serve as the primary database.
The secondary cluster also supports high availability on its own. That means the backup region has its own local redundancy and can handle internal zonal issues, rather than being a single point of failure waiting to take over.
Cross-region replication is not only a disaster recovery feature. Because the secondary cluster lives closer to users in another part of the world, it can reduce read latency for those users by serving queries from a nearby region instead of forcing every read back to Region A. This mirrors the Cloud SQL cross-region read replica model.
The secondary cluster also expands read capacity. It supports up to 20 read nodes, which lets you scale read compute independently in that region. So a secondary cluster can do two jobs at once. It sits ready to be promoted if the primary region goes down, and in the meantime it lowers read latency and adds read throughput for users near Region B.
For the Professional Cloud Database Engineer exam, the useful distinction is between protecting against a zonal failure and protecting against a regional failure. High availability is the zonal answer, and it stays within one region. Cross-region replication with a secondary cluster is the regional answer. When a scenario describes surviving a full regional outage, keeping a warm copy in another region, or serving and scaling reads for a geographically distributed user base, the secondary cluster is what fits.
Our Professional Cloud Database Engineer course covers AlloyDB cross-region replication alongside AlloyDB high availability and Cloud SQL cross-region read replicas, with practice questions that drill these distinctions.
