Manuelles Failover einer primären oder sekundären Instanz

In diesem Dokument wird beschrieben, wie Sie ein manuelles Failover einer primären oder sekundären Instanz durchführen.

Hochverfügbarkeit für primäre und sekundäre Instanzen

AlloyDB for PostgreSQL unterstützt Hochverfügbarkeit sowohl für primäre als auch für sekundäre Instanzen.

Hochverfügbarkeit für primäre Instanzen

Um Hochverfügbarkeit (HA) zu gewährleisten, hat jede primäre AlloyDB-Instanz einen aktiven Knoten und einen Standby-Knoten, die sich in verschiedenen Zonen befinden. Wenn der aktive Knoten nicht mehr verfügbar ist, führt AlloyDB automatisch ein Failover der primären Instanz auf den Standby-Knoten durch, der dann zum neuen aktiven Knoten wird.

Sie können jederzeit ein manuelles Failover Ihrer primären Instanz zum Standby-Knoten ausführen, auch wenn der aktive Knoten wie erwartet funktioniert. Wenn Sie einen manuellen Failover einleiten, führt AlloyDB die folgenden Schritte aus:

  1. Schaltet den primären Knoten offline.

  2. Der Standby-Knoten wird zum neuen aktiven Knoten.

  3. Reaktiviert den zuvor aktiven Knoten als neuen Standby-Knoten.

Beim manuellen Failover werden die aktiven und Standby-Rollen der Knoten Ihrer primären Instanz getauscht. Sie können jederzeit ein manuelles Failover auslösen, um diesen Austausch zu erzwingen.

Angenommen, Sie haben eine primäre Instanz, deren aktiver und Standby-Knoten sich in den Zonen us-central1-a bzw. us-central1-b befinden. Ein Ausfall in us-central1-a löst einen automatischen Failover aus, sodass die us-central1-b-Zone den aktiven Knoten hostet. Wenn Sie den aktiven Knoten lieber in der Zone us-central1-a behalten möchten, können Sie ein manuelles Failover initiieren. Dadurch werden die Knoten der primären Instanz in AlloyDB wieder an ihre ursprünglichen Standorte vor dem Ausfall verschoben.

Während der Wartung kommt es bei einer primären HA-Instanz und einer Basisinstanz in der Regel zu einer minimalen Wartungsausfallzeit von weniger als einer Sekunde. Da das manuelle Failover ein bewusstes und kontrolliertes Verfahren ist, ist es nicht dazu gedacht, unerwartete Hardware- oder Netzwerkfehler zu simulieren. Stattdessen können Sie die Hochverfügbarkeit Ihrer primären Instanz mit Fehlerinjektion testen.

Hochverfügbarkeit für sekundäre Instanzen

AlloyDB bietet Hochverfügbarkeit für sekundäre Instanzen, um die Notfallwiederherstellung zu unterstützen und Ausfallzeiten zu reduzieren, wenn eine sekundäre Instanz nicht mehr verfügbar ist.

Standardmäßig ist HA auf einer sekundären Instanz konfiguriert.

Eine sekundäre AlloyDB-Instanz enthält die folgenden Knoten:

  • Ein aktiver sekundärer Knoten, der auf Anfragen reagiert
  • Ein sekundärer Standby-Knoten

Die aktiven und Standby-Knoten befinden sich in zwei verschiedenen Zonen in einer Region. Wenn AlloyDB die Nichtverfügbarkeit des aktiven Knotens erkennt, wird ein Failover des aktiven Knotens auf den Standby-Knoten durchgeführt, der dann als neuer aktiver Knoten fungiert. Ihre Daten werden dann zum neuen aktiven Knoten umgeleitet. Dieser Vorgang wird als Failover bezeichnet.

Hinweise

  • Das von Ihnen verwendete Google Cloud -Projekt muss für den Zugriff auf AlloyDB aktiviert sein.
  • Sie benötigen eine der folgenden IAM-Rollen im Google Cloud Projekt, das Sie verwenden:
    • roles/alloydb.admin (die vordefinierte IAM-Rolle „AlloyDB Admin“)
    • roles/owner (einfache IAM-Rolle „Inhaber“)
    • roles/editor (einfache IAM-Rolle „Bearbeiter“)

    Wenn Sie keine dieser Rollen haben, wenden Sie sich an den Organisationsadministrator, um Zugriff anzufordern.

Manuelles Failover für eine primäre Instanz durchführen

Console

  1. Rufen Sie die Seite Cluster auf.

Zu den Clustern

  1. Klicken Sie in der Spalte Ressourcenname auf einen Clusternamen.

  2. Öffnen Sie im Bereich Instanzen in Ihrem Cluster das Menü „Instanzaktionen“ Ihrer primären Instanz.

  3. Klicken Sie auf Failover.

  4. Geben Sie im angezeigten Dialogfeld die ID der Instanz ein.

  5. Klicken Sie auf Failover auslösen.

gcloud

Führen Sie den Befehl gcloud alloydb instances failover aus:

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

Ersetzen Sie Folgendes:

  • INSTANCE_ID: Die ID der Instanz.
  • REGION_ID: Die Region, in der sich die Instanz befindet.
  • CLUSTER_ID: Die ID des Clusters, in dem sich die Instanz befindet.
  • PROJECT_ID: Die ID des Projekts, in dem sich der Cluster befindet.

So prüfen Sie, ob der Failover funktioniert hat:

  1. Notieren Sie sich vor dem Failover die Zonen der Knoten der primären Instanz.

  2. Notieren Sie sich nach dem Failover die neuen Zonen der beiden Knoten.

  3. Prüfen Sie, ob die Zonen der aktiven und Standby-Knoten getauscht wurden.

Manuelles Failover auf einer sekundären Instanz ausführen

Ein manuelles Failover einer sekundären Instanz ähnelt den Schritten, die für ein manuelles Failover der primären Instanz ausgeführt werden.

So führen Sie ein manuelles Failover für einen sekundären Cluster aus:

Console

  1. Rufen Sie in der Google Cloud Console die Seite Cluster auf.

    Zu den Clustern

  2. Klicken Sie in der Spalte Ressourcenname auf den Namen eines sekundären Clusters.

  3. Rufen Sie auf der Seite Übersicht den Abschnitt Instanzen in Ihrem Cluster auf, wählen Sie die sekundäre Instanz aus und klicken Sie auf Failover.

  4. Geben Sie im angezeigten Dialogfeld die ID der Instanz ein und klicken Sie auf Failover auslösen.

gcloud

Wenn Sie die gcloud CLI verwenden möchten, können Sie die Google Cloud CLI installieren und initialisieren oder Cloud Shell verwenden.

Mit dem Befehl gcloud alloydb instances failover können Sie erzwingen, dass eine sekundäre Instanz ein Failover auf ihren Standby-Server durchführt.

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

Ersetzen Sie Folgendes:

  • SECONDARY_INSTANCE_ID: Die ID der sekundären Instanz, für die Sie ein Failover durchführen möchten.
  • SECONDARY_CLUSTER_ID: Die ID des sekundären Clusters, dem die sekundäre Instanz zugeordnet ist.
  • REGION_ID: Die ID der Region der sekundären Instanz, z. B. us-central1.
  • PROJECT_ID: Die ID des Projekts des sekundären Clusters.

Nächste Schritte