Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Der Zweck einer Hochverfügbarkeitskonfiguration besteht darin, Ausfallzeiten zu reduzieren, wenn eine Datenbankclusterinstanz nicht mehr verfügbar ist. Dies kann passieren, wenn eine Instanz nicht mehr über genügend Arbeitsspeicher verfügt. Mit Hochverfügbarkeit sind Ihre Daten weiterhin für Clientanwendungen verfügbar.
Innerhalb eines Standorts besteht die Konfiguration aus einer primären Instanz und einem Standby-Replikat. Alle Schreibvorgänge, die an der primären Instanz ausgeführt werden, werden auf das Standby-Replikat repliziert, bevor eine Transaktion als Commit gemeldet wird. Bei einem Instanzausfall können Sie anfordern, dass das Standby-Replikat zur neuen primären Instanz wird.
Der Anwendungs-Traffic wird dann auf die neue primäre Instanz umgeleitet. Dieser Vorgang wird als Failover bezeichnet.
Sie können jederzeit manuell ein Failover auslösen. Das Failover umfasst die folgenden Schritte in der angegebenen Reihenfolge:
GDC nimmt die primäre Instanz offline.
GDC macht das Standby-Replikat zum neuen aktiven Datenbankcluster.
GDC löscht den vorherigen aktiven Datenbankcluster.
GDC erstellt ein neues Standby-Replikat.
Für AlloyDB Omni- und PostgreSQL-Datenbankcluster können Sie die Hochverfügbarkeit in derselben Zone aktivieren oder deaktivieren.
Vorhandenen Cluster aktualisieren
Sie können die Einstellungen für Hochverfügbarkeit für einen vorhandenen Datenbankcluster aktualisieren:
Console
Wählen Sie im Navigationsmenü Database Service aus.
Klicken Sie in der Liste der Datenbankcluster auf den Datenbankcluster, den Sie aktualisieren möchten.
Wählen Sie im Abschnitt Hochverfügbarkeit die Option Bearbeiten aus.
Wählen Sie Same-zone standby aktivieren aus, um die Verfügbarkeit einer Standby-Instanz in derselben Zone wie Ihr primärer Datenbankcluster zu aktivieren oder zu deaktivieren.
Klicken Sie auf Speichern.
Prüfen Sie, ob Ihr Datenbankcluster Ihr Update zur Hochverfügbarkeit widerspiegelt, indem Sie den Status in der Spalte Hochverfügbarkeit der Datenbankclusterliste ansehen.
gdcloud
Aktualisieren Sie die Hochverfügbarkeitskonfiguration Ihres Datenbankclusters:
Wenn Sie Hochverfügbarkeit für Ihren Datenbankcluster konfiguriert haben, können Sie ein Failover auslösen. Führen Sie die folgenden Schritte aus, um einen Failover auszulösen:
Console
Wählen Sie im Navigationsmenü Database Service aus.
Klicken Sie in der Liste der Datenbankcluster auf den Datenbankcluster, für den Sie ein Failover auslösen möchten. In Ihrem Datenbankcluster muss Hochverfügbarkeit aktiviert sein, damit ein Failover möglich ist.
Klicken Sie auf Failover.
Geben Sie die ID des Clusters für den Bestätigungssatz ein und klicken Sie auf Failover, um den Failover-Prozess auszulösen.
gdcloud
Failover für den Datenbankcluster auslösen:
gdclouddatabaseclustersfailoverCLUSTER_NAME
Ersetzen Sie CLUSTER_NAME durch den Namen des Datenbankclusters.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-04 (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`."]]