Hochverfügbarkeit in Kubernetes verwalten

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite erfahren Sie, wie Sie Hochverfügbarkeit (High Availability, HA) für Ihren Kubernetes-basierten AlloyDB Omni-Datenbankcluster aktivieren und testen. Für die hier beschriebenen Aufgaben sind grundlegende Kenntnisse über das Anwenden von Kubernetes-Manifestdateien und die Verwendung des kubectl-Befehlszeilentools erforderlich.

Übersicht

Sie können HA in Ihrem Datenbankcluster aktivieren, indem Sie den AlloyDB Omni Kubernetes-Operator anweisen, Standby-Replikate Ihrer primären Datenbankinstanz zu erstellen. Der AlloyDB Omni-Operator konfiguriert Ihren Datenbankcluster so, dass die Daten in diesem Replikat kontinuierlich aktualisiert werden und alle Änderungen an den Daten in Ihrer primären Instanz übernommen werden.

Hochverfügbarkeit aktivieren

Bevor Sie die Hochverfügbarkeit für Ihren Datenbankcluster aktivieren, muss Ihr Kubernetes-Cluster Folgendes enthalten:

  • Speicherplatz für zwei vollständige Kopien Ihrer Daten
  • Compute-Ressourcen für zwei parallel ausgeführte Datenbankinstanzen

So aktivieren Sie HA:

  1. Ändern Sie das Manifest des Datenbankclusters so, dass es unter dem Abschnitt spec einen Abschnitt availability enthält. In diesem Abschnitt wird die Anzahl der Stand-by-Geräte definiert, die Sie hinzufügen möchten, indem Sie den Parameter numberOfStandbys festlegen.

    spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS

    Ersetzen Sie NUMBER_OF_STANDBYS durch die Anzahl der Stand-by-Instanzen, die Sie hinzufügen möchten. Der Höchstwert ist 5. Wenn Sie HA einrichten und sich nicht sicher sind, wie viele Standby-Instanzen Sie benötigen, legen Sie den Wert zuerst auf 1 oder 2 fest.

  2. Wenden Sie das Manifest noch einmal an.

Hochverfügbarkeit deaktivieren

So deaktivieren Sie HA:

  1. Setzen Sie numberOfStandbys im Manifest des Clusters auf 0:

    spec:
  availability:
    numberOfStandbys: 0

  2. Wenden Sie das Manifest noch einmal an.

HA in einem Datenbankcluster prüfen

Wenn Sie den aktuellen HA-Status eines Datenbankclusters aufrufen möchten, prüfen Sie die HAReady-Bedingung des Status dieses Clusters. Wenn dieser Wert für status auf True festgelegt ist, ist HA für den Datenbankcluster eingerichtet und funktioniert.

Führen Sie den folgenden Befehl aus, um diesen Wert in der Befehlszeile zu prüfen:

kubectl get dbcluster.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o jsonpath={.status.conditions[?(@.type == \'HAReady\')]} -n NAMESPACE

Ersetzen Sie Folgendes:

  • DB_CLUSTER_NAME: der Name des Datenbankclusters.

  • NAMESPACE: der Namespace des Datenbankclusters.

Failover auf eine Standby-Instanz ausführen

Wenn Ihre primäre Instanz für einen konfigurierbaren Zeitraum nicht verfügbar ist, führt der AlloyDB Omni Operator automatisch ein Failover von der primären Datenbankinstanz zur Standby-Instanz aus. Die Standardzeit zum Auslösen des automatischen Failovers beträgt 90 Sekunden.

Failover sind eine gute Option, wenn Sie sich schnell von einem unerwarteten Fehler erholen und Ausfallzeiten minimieren möchten, auch wenn dies bedeutet, dass möglicherweise eine geringe Menge an Daten verloren geht, wenn die primäre Datenbank nicht mehr verfügbar ist, bevor das Backup vollständig aktualisiert wurde.

Der AlloyDB Omni Operator unterstützt sowohl das automatische als auch das manuelle Failover. Das automatische Failover ist standardmäßig aktiviert.

Ein Failover führt zu der folgenden Ereignisabfolge:

  1. Der AlloyDB Omni-Operator nimmt die primäre Datenbankinstanz offline.

  2. Der AlloyDB Omni-Operator stuft das Standby-Replikat zur neuen primären Datenbankinstanz hoch.

  3. Der AlloyDB Omni Operator löscht die vorherige primäre Datenbankinstanz.

  4. Der AlloyDB Omni-Operator erstellt ein neues Standby-Replikat.

Automatischen Failover deaktivieren

Automatische Failover sind in Datenbankclustern standardmäßig aktiviert.

So deaktivieren Sie ein Failover:

  1. Setzen Sie enableAutoFailover im Manifest des Clusters auf false:

    spec:
  availability:
    enableAutoFailover: false

Einstellungen für den automatischen Failover-Trigger anpassen

Mit den Einstellungen können Sie automatische Failover für jeden Datenbankcluster anpassen.

Der AlloyDB Omni-Operator führt alle 30 Sekunden regelmäßige Systemdiagnosen durch. Wenn eine Instanz den Schwellenwert für den automatischen Failover erreicht hat, löst der AlloyDB Omni-Operator einen automatischen Failover aus.

Der Standardwert für den Schwellenwert für die automatische Failover-Auslösung ist 3. Der Schwellenwert ist die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor ein Failover ausgelöst wird. So ändern Sie den Grenzwert: Legen Sie autoFailoverTriggerThreshold im Manifest des Clusters auf einen ganzzahligen Wert fest:

```yaml
spec:
  availability:
    autoFailoverTriggerThreshold: TRIGGER_THRESHOLD
```

Ersetzen Sie Folgendes:

  • TRIGGER_THRESHOLD: Ein Ganzzahlwert für die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor ein Failover ausgelöst wird. Der Standardwert ist 3.

Manuellen Failover auslösen

Wenn Sie ein manuelles Failover auslösen möchten, erstellen Sie ein Manifest für eine neue Failover-Ressource und wenden Sie es an:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Failover
metadata:
  name: FAILOVER_NAME
  namespace: NAMESPACE
spec:
  dbclusterRef: DB_CLUSTER_NAME

Ersetzen Sie Folgendes:

  • FAILOVER_NAME: Ein Name für diese Ressource, z. B. failover-1.

  • NAMESPACE: Der Namespace für diese Failover-Ressource. Er muss mit dem Namespace des Datenbankclusters übereinstimmen, auf den sie angewendet wird.

  • DB_CLUSTER_NAME: Der Name des Datenbankclusters, für den ein Failover durchgeführt werden soll.

Führen Sie zur Überwachung des Failovers den folgenden Befehl aus:

kubectl get failover FAILOVER_NAME -o jsonpath={.status.state} -n NAMESPACE

Ersetzen Sie Folgendes:

  • FAILOVER_NAME: Der Name, den Sie der Failover-Ressource beim Erstellen zugewiesen haben.

  • NAMESPACE: der Namespace des Datenbankclusters.

Der Befehl gibt Success zurück, nachdem die neue primäre Datenbankinstanz einsatzbereit ist. Informationen zum Überwachen des Status der neuen Standby-Instanz finden Sie im nächsten Abschnitt.

Zur Standby-Instanz wechseln

Ein Switchover wird durchgeführt, wenn Sie Ihre Einrichtung für die Notfallwiederherstellung oder andere geplante Aktivitäten testen möchten, bei denen die Rollen der primären Datenbank und des Standby-Replikats getauscht werden müssen.

Nach Abschluss des Switchovers werden die Rollen der primären Datenbankinstanz und des Standby-Replikats zusammen mit der Richtung der Replikation umgekehrt. Sie müssen sich für Switchovers entscheiden, wenn Sie die Einrichtung zur Notfallwiederherstellung ohne Datenverlust testen möchten.

Der AlloyDB Omni Operator unterstützt die manuelle Übernahme.

Ein Switchover führt zu den folgenden Ereignissen:

  1. Der AlloyDB Omni-Operator nimmt die primäre Datenbankinstanz offline.

  2. Der AlloyDB Omni-Operator stuft das Standby-Replikat zur neuen primären Datenbankinstanz hoch.

  3. Der AlloyDB Omni Operator schaltet die bisherige primäre Datenbankinstanz auf ein Standby-Replikat um.

.

Switchover durchführen

Prüfen Sie vor dem Switchover Folgendes:

Um eine Übernahme durchzuführen, erstellen und wenden Sie ein Manifest für eine neue Übernahmeressource an:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: Switchover
metadata:
    name: SWITCHOVER_NAME
spec:
     dbclusterRef: DB_CLUSTER_NAME
     newPrimary: STANBDY_REPLICA_NAME

Ersetzen Sie Folgendes:

  • SWITCHOVER_NAME: Ein Name für diese Switchover-Ressource, z. B. switchover-1.

  • DB_CLUSTER_NAME: Der Name der primären Datenbankinstanz, auf die sich der Switchover-Vorgang bezieht.

  • STANBDY_REPLICA_NAME: Der Name der Datenbankinstanz, die Sie als neue primäre Instanz festlegen möchten.

    Führen Sie den folgenden Befehl aus, um den Namen des Standby-Replikats zu ermitteln: posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Standby-Replikat als schreibgeschützte Instanz verwenden

So verwenden Sie eine Standby-Replika als schreibgeschützte Instanz:

  1. Ändern Sie das Manifest des Datenbankclusters, um den Parameter enableStandbyAsReadReplica auf true festzulegen.

    spec:
  availability:
    enableStandbyAsReadReplica: true

  2. Wenden Sie das Manifest noch einmal an.

  3. Prüfen Sie, ob der schreibgeschützte Endpunkt im Feld status des DBCluster-Objekts angegeben ist:

    kubectl describe dbcluster -n NAMESPACE DB_CLUSTER_NAME

    Die folgende Beispielantwort enthält den Endpunkt der schreibgeschützten Instanz:

      Status:
  [...]
  Primary: 
    [...]
    Endpoints:
      Name: Read-Write
      Value: 10.128.0.81:5432
      Name: Read-Only
      Value: 10.128.0.82:5432