This page provides an overview of AlloyDB for PostgreSQL cross-region replication.
AlloyDB cross-region replication lets you create secondary clusters and instances from a primary cluster to make the resources available in different regions, in the event of an outage in the primary region. These secondary clusters and instances function as copies of your primary cluster and instance resources.
Key concepts in this page include the following:
- Primary cluster. A read-write cluster in a single region.
- Secondary cluster. A read-only cluster in a different region than the primary, that replicates from the primary cluster asynchronously. In the event of a failure of an AlloyDB primary cluster, you can promote a secondary cluster to a primary cluster.
- Secondary instance. A read-only leader of a secondary cluster. It is responsible for receiving a replication stream from a primary cluster. The replication stream updates the storage volume in the secondary region based on the storage volume in the primary region. If a secondary cluster is promoted to a primary cluster, the secondary instance becomes the primary instance.
- Active secondary node. A node that's part of the secondary instance. This node remains active and responds to requests.
- Stand-by secondary node. A node that's part of the secondary instance. If AlloyDB detects unavailability of the active node, it promotes the standby node to act as the new active node.
Benefits
The benefits of cross-region replication on AlloyDB include the following:
Disaster recovery. In the event the primary cluster's region becomes unavailable, you can promote AlloyDB resources in another region to serve requests.
Reduced downtime. Support of high availability (HA) on secondary clusters reduces downtime during maintenance events or unplanned outages.
Geographically distributed data. Distributing the data geographically brings the data closer to you and decreases read latency.
Geographic load balancing. In the event of slow or overloaded connections in one region, you can route traffic to another region.
Improved read performance. It makes AlloyDB resources available closer to your application's region.
How to work with cross-region replication
Working with AlloyDB cross-region replication involves the following tasks:
Create a secondary cluster. A secondary cluster is a continuously updated copy of your AlloyDB primary cluster.
View a secondary cluster. After you create a secondary cluster, you can view its details in the Clusters page in the Google Cloud console.
Promote a secondary cluster. If you need to read from or write to the data in a secondary cluster, you must first promote it into a fully-featured, stand-alone primary cluster. When you promote a secondary cluster, the cluster's secondary instance is also promoted as a primary instance with read and write capabilities.
There are two common scenarios for promoting your secondary cluster to a primary cluster:
- Regional migration. Perform a planned migration of the AlloyDB resources from their primary region to another region.
- Disaster recovery. Rapidly activate the AlloyDB resources in a secondary region in the event that the resources in the primary region become unavailable. Due to replication lag, some data loss might occur.
Promoting a secondary cluster converts it to a standalone cluster with a fully functional primary instance, including read and write capabilities. The promoted cluster no longer replicates the data from the primary cluster it was formerly associated with.
Add read pool instances. After you promote a secondary cluster to a primary cluster, you can add read pool instances to the promoted cluster. Read pool instances are not supported on secondary instances.
Configure automated and continuous backups. By default, AlloyDB does not copy backup configuration from the old primary cluster to the newly promoted cluster. However, you can configure automated and continuous backups on a newly promoted cluster.