Manuelles Failover einer primären oder sekundären Instanz

In diesem Dokument wird beschrieben, wie Sie einen manuellen Failover für eine primäre oder sekundäre Instanz ausführen.

Hochverfügbarkeit bei primären und sekundären Instanzen

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

Hochverfügbarkeit bei primären Instanzen

Um eine hohe Verfügbarkeit (High Availability, HA) zu gewährleisten, hat jede AlloyDB-Primärinstanz sowohl einen aktiven als auch 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 den Failover Ihrer primären Instanz jederzeit manuell auf den Standbyknoten ausführen, auch wenn der aktive Knoten wie erwartet funktioniert. Wenn Sie einen manuellen Failover einleiten, führt AlloyDB die folgenden Schritte aus:

  1. Der primäre Knoten wird offline geschaltet.

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

  3. Der zuvor aktive Knoten wird als neuer Standbyknoten reaktiviert.

Beim manuellen Failover werden die aktiven und Standby-Rollen der Knoten Ihrer primären Instanz getauscht. Sie können jederzeit einen manuellen Failover auslösen, wenn dieser Austausch erfolgen soll.

Angenommen, Sie haben eine primäre Instanz, deren aktiver und Standby-Knoten sich in den Zonen us-central1-a und us-central1-b befinden. Ein Ausfall in us-central1-a löst einen automatischen Failover aus, wodurch die Zone us-central1-b den aktiven Knoten hostet. Wenn Sie den aktiven Knoten in der Zone us-central1-a beibehalten möchten, können Sie ein manuelles Failover auslösen, damit AlloyDB die Knoten der primären Instanz wieder an ihren Standort vor dem Ausfall zurückversetzt.

Während der Wartung kommt es bei einer primären Hochverfügbarkeits- und einer Basisinstanz in der Regel zu einer minimalen Wartungsausfallzeit von weniger als einer Sekunde. Da das manuelle Failover ein beabsichtigtes und kontrolliertes Verfahren ist, ist es nicht für die Simulation unerwarteter Hardware- oder Netzwerkfehler vorgesehen. Stattdessen können Sie die Hochverfügbarkeit Ihrer primären Instanz mithilfe von Fehlerinjektion testen.

Hochverfügbarkeit auf sekundären 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 verfügbar ist.

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

Eine sekundäre AlloyDB-Instanz umfasst die folgenden Knoten:

  • Ein aktiver sekundärer Knoten, der auf Anfragen reagiert
  • Einen sekundären Standbyknoten

Die aktiven und Standby-Knoten befinden sich in zwei verschiedenen Zonen in einer Region. Wenn AlloyDB feststellt, dass der aktive Knoten nicht verfügbar ist, wird ein Failover auf den Standby-Knoten ausgeführt, der dann als neuer aktiver Knoten fungiert. Ihre Daten werden dann an den neuen aktiven Knoten weitergeleitet. Dieser Vorgang wird als failover bezeichnet.

Hinweise

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

    Wenn Sie keine dieser Rollen haben, wenden Sie sich an den Administrator Ihrer Organisation, um Zugriff anzufordern.

Manuelles Failover für eine primäre Instanz ausfü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 des aktiven und des Standby-Knotens vertauscht sind.

Manuelles Failover auf einer sekundären Instanz ausführen

Das manuelle Failover einer sekundären Instanz ähnelt dem manuellen Failover der primären Instanz.

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

Konsole

  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. Gehen Sie auf der Seite Übersicht zum Abschnitt Instanzen in Ihrem Cluster, 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 eine sekundäre Instanz zum Failover auf die Standby-Instanz zwingen.

 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, auf die Sie den Failover ausführen möchten.
  • SECONDARY_CLUSTER_ID: Die ID des sekundären Clusters, mit dem die sekundäre Instanz verknüpft 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