Auf dieser Seite finden Sie die Dokumentation für die Version 15.5.4 von AlloyDB Omni.
Aktuelle AlloyDB Omni-Dokumentation

Diese Seite wurde von der Cloud Translation API übersetzt.

Hochverfügbarkeit in Kubernetes verwalten

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

Übersicht

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

Hochverfügbarkeit aktivieren

Bevor Sie die Hochverfügbarkeit für Ihren Datenbankcluster aktivieren, müssen Sie dafür sorgen, dass Ihr Kubernetes-Cluster die folgenden Voraussetzungen erfüllt:

Speicherplatz für zwei vollständige Kopien Ihrer Daten
Rechenressourcen für zwei parallel ausgeführte Datenbankinstanzen

So aktivieren Sie die HA:

Ä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 Standbys festgelegt, die Sie hinzufügen möchten. Legen Sie dazu den Parameter numberOfStandbys fest.
```
spec:
  availability:
    numberOfStandbys: NUMBER_OF_STANDBYS
```
Ersetzen Sie NUMBER_OF_STANDBYS durch die Anzahl der Standbys, die Sie hinzufügen möchten. Der Maximalwert ist 5. Wenn Sie HA einrichten und sich nicht sicher sind, wie viele Standbys Sie benötigen, legen Sie den Wert zuerst auf 1 oder 2 fest.
Wenden Sie das Manifest noch einmal an.

Hochverfügbarkeit deaktivieren

So deaktivieren Sie die HA:

Legen Sie im Manifest des Clusters numberOfStandbys auf 0 fest:
```
spec:
  availability:
    numberOfStandbys: 0
```
Wenden Sie das Manifest noch einmal an.

HA in einem Datenbankcluster prüfen

Um den aktuellen HA-Status eines Datenbankclusters aufzurufen, sehen Sie sich die HAReady Bedingung des Status dieses Clusters an. Wenn für diesen Wert 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: den Namespace des Datenbankclusters.

Failover auf eine Standby-Instanz

Wenn Ihre primäre Instanz länger als 90 Sekunden nicht verfügbar ist, führt der AlloyDB Omni-Betriebssystemmanager automatisch ein Failover von der primären Datenbankinstanz zur Standby-Instanz aus.

Failover sind eine gute Option, wenn Sie sich schnell von einem unerwarteten Ausfall erholen und die Ausfallzeit minimieren möchten, auch wenn dies möglicherweise den Verlust einer kleinen Menge an Daten bedeutet, wenn die primäre Datenbank nicht verfügbar ist, bevor die Sicherung vollständig aktualisiert wurde.

Der AlloyDB Omni-Betriebsmodus unterstützt sowohl automatisches als auch manuelles Failover. Der automatische Failover ist standardmäßig aktiviert.

Ein Failover führt zur folgenden Abfolge von Ereignissen:

Der AlloyDB Omni-Betriebsmitarbeiter stellt die primäre Datenbankinstanz offline.
Der AlloyDB Omni-Betriebsleiter stuft das Standby-Replikat als neue primäre Datenbankinstanz hoch.
Der AlloyDB Omni-Operator löscht die vorherige primäre Datenbankinstanz.
Der AlloyDB Omni-Betriebsmanager erstellt ein neues Standby-Replikat.

Automatischen Failover deaktivieren

Automatische Failover sind in Datenbankclustern standardmäßig aktiviert.

So deaktivieren Sie ein Failover:

Legen Sie im Manifest des Clusters enableAutoFailover auf false fest:
```
spec:
  availability:
    enableAutoFailover: false
```
Wenden Sie das Manifest noch einmal an.

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, der mit dem Namespace des Datenbankclusters übereinstimmen muss, auf den sie sich bezieht.
DB_CLUSTER_NAME: der Name des Datenbankclusters, auf den umgeschaltet werden soll.

Führen Sie den folgenden Befehl aus, um den Failover zu überwachen:

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: den Namespace des Datenbankclusters.

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

Zu einer Standby-Instanz wechseln

Ein Switchover wird ausgeführt, wenn Sie Ihre Notfallwiederherstellungseinrichtung 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 sowie die Replikationsrichtung umgekehrt. Sie müssen sich für einen Switchover entscheiden, wenn Sie die Tests Ihrer Notfallwiederherstellungseinrichtung ohne Datenverlust besser steuern möchten.

Der AlloyDB Omni-Betriebsmodus unterstützt den manuellen Wechsel.

Ein Switchover führt zur folgenden Abfolge von Ereignissen:

Der AlloyDB Omni-Betriebsmitarbeiter stellt die primäre Datenbankinstanz offline.
Der AlloyDB Omni-Betriebsleiter stuft das Standby-Replikat als neue primäre Datenbankinstanz hoch.
Der AlloyDB Omni-Betriebsmanager wechselt die vorherige primäre Datenbankinstanz zu einem Standby-Replikat.

Switchover durchführen

Prüfen Sie vor dem Switchover Folgendes:

Prüfen Sie, ob sowohl die primäre Datenbankinstanz als auch das Standby-Replikat fehlerfrei sind. Weitere Informationen finden Sie unter AlloyDB Omni verwalten und überwachen.
Prüfen Sie, ob der aktuelle HA-Status HAReady lautet. Weitere Informationen finden Sie unter HA in einem Datenbankcluster prüfen.

Wenn Sie einen Switchover ausführen möchten, erstellen und wenden Sie ein Manifest für eine neue Switchover-Ressource 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 Umschaltressource, z. B. switchover-1.
DB_CLUSTER_NAME: Der Name der primären Datenbankinstanz, auf die der Umstellungsvorgang angewendet wird.
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-Repliks zu ermitteln: posix-terminal kubectl get instances.alloydbomni.internal.dbadmin.goog

Ein Standby-Replikat als schreibgeschützte Instanz verwenden

So verwenden Sie ein Standby-Replikat als Lesezugriffs-Instanz:

Ändern Sie das Manifest des Datenbankclusters, um den Parameter enableStandbyAsReadReplica auf true festzulegen.
```
spec:
  availability:
    enableStandbyAsReadReplica: true
```
Wenden Sie das Manifest noch einmal an.

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 zeigt 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