Stay organized with collections
Save and categorize content based on your preferences.
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.
GDC turns the standby replica into the new active
database cluster.
GDC deletes the previous active database cluster.
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
In the navigation menu, select Database Service.
From the database cluster list, click the database cluster to update.
Select editEdit in
the High availability section.
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.
Click Save.
Verify your database cluster reflects your high availability update by
viewing its status in the High availability column of the database
cluster list.
gdcloud
Update your database cluster's high availability configuration:
If you have configured high availability for your database cluster, you can
trigger a failover. To trigger a failover, complete the following steps:
Console
In the navigation menu, select Database Service.
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.
Click Failover.
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:
gdclouddatabaseclustersfailoverCLUSTER_NAME
Replace CLUSTER_NAME with the name of the database
cluster.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# Configure high availability\n\nThe purpose of a high availability configuration is to reduce downtime when a\ndatabase cluster instance becomes unavailable. This might happen when an\ninstance runs out of memory. With high availability, your data continues to be\navailable to client applications.\n| **Note:** High availability is only available for the AlloyDB Omni and PostgreSQL database engines at this time.\n\nWithin a site, the configuration is made up of a primary instance and a standby\nreplica. All writes made to the primary instance are replicated to the standby\nreplica before a transaction is reported as committed. In the event of an\ninstance failure, you can request that the standby replica become the new primary instance.\nApplication traffic is then rerouted to the new primary instance. This process is called a\n*failover*.\n\nYou can [manually trigger a failover](#trigger-failover) at any time. The\nfailover involves the following process, in order:\n\n1. GDC takes the primary instance offline.\n\n2. GDC turns the standby replica into the new active\n database cluster.\n\n3. GDC deletes the previous active database cluster.\n\n4. GDC creates a new standby replica.\n\nFor AlloyDB Omni and PostgreSQL database clusters, you can enable or disable same zone high\navailability.\n\nUpdate an existing cluster\n--------------------------\n\nYou can update your high availability settings for an existing database cluster: \n\n### Console\n\n1. In the navigation menu, select **Database Service**.\n\n2. From the database cluster list, click the database cluster to update.\n\n3. Select edit **Edit** in\n the **High availability** section.\n\n4. Select **Enable same zone standby** to either toggle on or off the\n availability of a standby instance in the same zone as your primary\n database cluster.\n\n5. Click **Save**.\n\n6. Verify your database cluster reflects your high availability update by\n viewing its status in the **High availability** column of the database\n cluster list.\n\n### gdcloud\n\n1. Update your database cluster's high availability configuration:\n\n gdcloud database clusters update \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e \\\n --availability-type \u003cvar translate=\"no\"\u003eHA_TYPE\u003c/var\u003e\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e: the name of the database cluster.\n - \u003cvar translate=\"no\"\u003eHA_TYPE\u003c/var\u003e: the high availability level for the database cluster. You can set `zonal` or `zonal_ha`. The `zonal` value is set by default.\n2. Verify your database cluster reflects your high availability update:\n\n gdcloud database clusters list\n\n### API\n\n1. Update your database cluster's high availability configuration:\n\n kubectl patch dbcluster.\u003cvar translate=\"no\"\u003eDBENGINE_NAME\u003c/var\u003e.dbadmin.gdc.goog \u003cvar translate=\"no\"\u003eDBCLUSTER_NAME\u003c/var\u003e \\\n -n \u003cvar translate=\"no\"\u003eUSER_PROJECT\u003c/var\u003e \\\n -p '{\"spec\": {\"availability\": {\"enableHighAvailability\": \u003cvar translate=\"no\"\u003eHA_ENABLED\u003c/var\u003e}}}' \\\n --type=merge\n\n Replace the following variables:\n - \u003cvar translate=\"no\"\u003eDBENGINE_NAME\u003c/var\u003e: the name of the database engine. This is one of `alloydbomni`, `postgresql`, or `oracle`.\n - \u003cvar translate=\"no\"\u003eDBCLUSTER_NAME\u003c/var\u003e: the name of the database cluster.\n - \u003cvar translate=\"no\"\u003eUSER_PROJECT\u003c/var\u003e: the name of the user project where the database cluster was created.\n - \u003cvar translate=\"no\"\u003eHA_ENABLED\u003c/var\u003e: the high availability level for the database cluster. You can set `true` or `false`. The `false` value is set by default.\n2. Verify your database cluster reflects your high availability update:\n\n kubectl get dbcluster.\u003cvar translate=\"no\"\u003eDBENGINE_NAME\u003c/var\u003e.dbadmin.gdc.goog \u003cvar translate=\"no\"\u003eDBCLUSTER_NAME\u003c/var\u003e \\\n -n \u003cvar translate=\"no\"\u003eUSER_PROJECT\u003c/var\u003e \\\n -o yaml\n\nTrigger a failover\n------------------\n\nIf you have configured high availability for your database cluster, you can\ntrigger a failover. To trigger a failover, complete the following steps: \n\n### Console\n\n1. In the navigation menu, select **Database Service**.\n\n2. From the database cluster list, click the database cluster to trigger a\n failover for. Your database cluster must have\n [high availability enabled](#update-existing-cluster-ha) to be eligible\n for a failover.\n\n3. Click **Failover**.\n\n4. Type the cluster's ID for the confirmation phrase and click **Failover**\n to trigger the failover process.\n\n### gdcloud\n\n- Trigger the failover for the database cluster:\n\n gdcloud database clusters failover \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e\n\n Replace \u003cvar translate=\"no\"\u003eCLUSTER_NAME\u003c/var\u003e with the name of the database\n cluster.\n\n### API\n\n apiVersion: fleet.dbadmin.gdc.goog/v1\n kind: Failover\n metadata:\n name: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eFAILOVER_NAME\u003c/span\u003e\u003c/var\u003e\n spec:\n dbclusterRef: \u003cvar translate=\"no\"\u003e\u003cspan class=\"devsite-syntax-l devsite-syntax-l-Scalar devsite-syntax-l-Scalar-Plain\"\u003eDBCLUSTER_NAME\u003c/span\u003e\u003c/var\u003e\n\nReplace the following variables:\n\n- \u003cvar translate=\"no\"\u003eDBCLUSTER_NAME\u003c/var\u003e, the name of the database cluster.\n- \u003cvar translate=\"no\"\u003eFAILOVER_NAME\u003c/var\u003e, the unique name of the failover, for example `failover-sample`."]]
