Fail over a primary or secondary instance manually

This document describes how to manually fail over a primary or secondary instance.

High availability on primary and secondary instances

AlloyDB for PostgreSQL supports high availability on both primary and secondary instances.

High availability on primary instances

To help ensure high availability (HA), every AlloyDB primary instance has both an active node and a standby node, which are located in different zones. If the active node becomes unavailable, then AlloyDB automatically fails over the primary instance to its standby node, making it the new active node.

You can manually fail over your primary instance to its standby node at any time, even if the active node is working as expected. When you initiate a manual failover, AlloyDB does the following:

1. Takes the primary node offline.

2. Turns the standby node into the new active node.

3. Reactivates the previous active node as the new standby node.

Manual failover swaps the active and standby roles of the nodes of your primary instance. You can trigger a manual failover any time that you want this exchange to occur.

For example, imagine that you have a primary instance whose active and standby nodes reside in the us-central1-a and us-central1-b zones, respectively. An outage in us-central1-a triggers an automatic failover, resulting in the us-central1-b zone hosting the active node. If you prefer to keep the active node in the us-central1-a zone, then you can initiate a manual failover to cause AlloyDB to swap the primary instance nodes back to their pre-outage locations.

During maintenance operations, an HA primary instance and a basic instance typically experience minimal maintenance downtime of less than a second. Because manual failover is an intentional and controlled procedure, it isn't intended for simulating unexpected hardware or network faults. Instead, you can test high availability for your primary instance by using fault injection.

High availability on secondary instances

AlloyDB offers HA on secondary instances to support disaster recovery and to reduce downtime when a secondary instance becomes unavailable.

By default, HA is configured on a secondary instance.

An AlloyDB secondary instance includes the following nodes:

• An active secondary node, which responds to requests
• A standby secondary node

The active and standby nodes are located in two different zones in a region. If AlloyDB detects unavailability of the active node, the active node fails over to the standby node to act as the new active node. Your data is then rerouted to the new active node. This process is called a failover.

Perform a manual failover on a primary instance

gcloud alloydb instances failover INSTANCE_ID \
    --region=REGION_ID \
    --cluster=CLUSTER_ID \
    --project=PROJECT_ID

To confirm that the failover worked, follow these steps:

1. Before performing the failover, note the zones of the primary instance's nodes.

2. After running the failover, note the two nodes' new zones.

3. Confirm that the zones of the active and standby nodes have switched places.

Perform a manual failover on a secondary instance

Failing over a secondary instance manually is similar to the steps followed for failing over the primary instance manually.

To fail over a secondary cluster manually, follow these steps:

 gcloud alloydb instances failover SECONDARY_INSTANCE_ID \
 --cluster=SECONDARY_CLUSTER_ID \
 --region=REGION_ID \
 --project=PROJECT_ID

What's next

• Work with cross-region replication