Configure high availability

The purpose of a high availability configuration is to reduce downtime when a database cluster instance becomes unavailable. This might happen when an instance runs out of memory. With high availability, your data continues to be available to client applications.

Within a site, the configuration is made up of a primary instance and a standby replica. All writes made to the primary instance are replicated to the standby replica before a transaction is reported as committed. In the event of an instance failure, you can request that the standby replica become the new primary instance. Application traffic is then rerouted to the new primary instance. This process is called a failover.

You can manually trigger a failover at any time. The failover involves the following process, in order:

  1. GDC takes the primary instance offline.

  2. GDC turns the standby replica into the new active database cluster.

  3. GDC deletes the previous active database cluster.

  4. GDC creates a new standby replica.

For AlloyDB Omni and PostgreSQL database clusters, you can enable or disable same zone high availability.

Update an existing cluster

You can update your high availability settings for an existing database cluster:

Console

  1. In the navigation menu, select Database Service.

  2. From the database cluster list, click the database cluster to update.

  3. Select edit Edit in the High availability section.

    Edit the high availability settings of a database cluster.

  4. Select Enable same zone standby to either toggle on or off the availability of a standby instance in the same zone as your primary database cluster.

  5. Click Save.

  6. Verify your database cluster reflects your high availability update by viewing its status in the High availability column of the database cluster list.

gdcloud

  1. Update your database cluster's high availability configuration:

    gdcloud database clusters update CLUSTER_NAME \
    --availability-type HA_TYPE

    Replace the following:

    • CLUSTER_NAME: the name of the database cluster.
    • HA_TYPE: the high availability level for the database cluster. You can set zonal or zonal_ha. The zonal value is set by default.

  2. Verify your database cluster reflects your high availability update:

    gdcloud database clusters list

API

  1. Update your database cluster's high availability configuration:

      kubectl patch dbcluster.DBENGINE_NAME.dbadmin.gdc.goog DBCLUSTER_NAME \
    -n USER_PROJECT \
    -p '{"spec": {"availability": {"enableHighAvailability": HA_ENABLED}}}' \
    --type=merge

    Replace the following variables:

    • DBENGINE_NAME: the name of the database engine. This is one of alloydbomni, postgresql, or oracle.
    • DBCLUSTER_NAME: the name of the database cluster.
    • USER_PROJECT: the name of the user project where the database cluster was created.
    • HA_ENABLED: the high availability level for the database cluster. You can set true or false. The false value is set by default.

  2. Verify your database cluster reflects your high availability update:

    kubectl get dbcluster.DBENGINE_NAME.dbadmin.gdc.goog DBCLUSTER_NAME \
  -n USER_PROJECT \
  -o yaml

Trigger a failover

If you have configured high availability for your database cluster, you can trigger a failover. To trigger a failover, complete the following steps:

Console

  1. In the navigation menu, select Database Service.

  2. From the database cluster list, click the database cluster to trigger a failover for. Your database cluster must have high availability enabled to be eligible for a failover.

  3. Click Failover.

  4. Type the cluster's ID for the confirmation phrase and click Failover to trigger the failover process.

gdcloud

  • Trigger the failover for the database cluster:

    gdcloud database clusters failover CLUSTER_NAME

    Replace CLUSTER_NAME with the name of the database cluster.

API 

  apiVersion: fleet.dbadmin.gdc.goog/v1
  kind: Failover
  metadata:
    name: FAILOVER_NAME
  spec:
    dbclusterRef: DBCLUSTER_NAME

Replace the following variables:

  • DBCLUSTER_NAME, the name of the database cluster.
  • FAILOVER_NAME, the unique name of the failover, for example failover-sample.