Auf dieser Seite finden Sie die Dokumentation für AlloyDB Omni Version 15.7.0.
Unter Dokumentationsversionen für AlloyDB Omni können Sie eine andere Version auswählen.

Diese Seite wurde von der Cloud Translation API übersetzt.

Hochverfügbarkeit in Kubernetes verwalten

In diesem Dokument wird beschrieben, wie Sie die Hochverfügbarkeit (High Availability, HA) in Ihrem Kubernetes-basierten AlloyDB Omni-Datenbankcluster aktivieren und testen. In diesem Dokument wird davon ausgegangen, dass Sie Grundkenntnisse zum Anwenden von Kubernetes-Manifestdateien und zur Verwendung des kubectl-Befehlszeilentools haben.

Übersicht

Sie aktivieren die Hochverfügbarkeit in Ihrem Datenbankcluster, indem Sie den AlloyDB Omni Kubernetes-Operator so konfigurieren, dass Standby-Replikate Ihrer primären Datenbankinstanz erstellt werden. Der AlloyDB Omni-Betriebsmodus konfiguriert Ihren Datenbankcluster so, dass die Daten in diesem Replikat kontinuierlich aktualisiert werden. Außerdem werden alle Datenänderungen 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 mit dem Parameter numberOfStandbys die Anzahl der hinzuzufügenden Standbys angegeben.
```
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 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

Den Status der Hochverfügbarkeit in einem Datenbankcluster können Sie anhand des HAReady-Status prüfen. Wenn der Status von HAReady True ist, ist die Hochverfügbarkeit aktiviert und funktioniert im Cluster. Wenn False angezeigt wird, ist die Funktion zwar aktiviert, aber noch nicht einsatzbereit, da sie gerade eingerichtet wird.

Führen Sie folgenden Befehl aus, um den HAReady-Status über die kubectl-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 für einen konfigurierbaren Zeitraum nicht verfügbar ist, führt der AlloyDB Omni-Betriebssystemmanager automatisch ein Failover von der primären Datenbankinstanz auf die Standby-Instanz aus. Mit den folgenden Parametern wird festgelegt, wann ein automatischer Failover gestartet wird:

Die Zeit zwischen den Systemdiagnosen (Standardwert: 30 Sekunden)
Die Anzahl der aufeinanderfolgenden fehlgeschlagenen Systemdiagnosen (Standardwert: 3)

Ein automatischer Failover wird gestartet, nachdem die angegebene Anzahl aufeinanderfolgender fehlgeschlagener Systemdiagnosen aufgetreten ist. Zwischen den einzelnen fehlgeschlagenen Systemdiagnosen liegt die angegebene Zeitspanne. Wenn die Standardwerte beibehalten werden, erfolgt nach drei aufeinanderfolgenden Systemdiagnosefehlern, die jeweils 30 Sekunden auseinanderliegen, ein automatisches Failover.

Ein manuelles Failover ist eine gute Option, wenn Sie nach einem unerwarteten Ausfall schnell wiederhergestellt werden und die Ausfallzeit minimieren möchten.

Der AlloyDB Omni-Operator 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-Betreiber stellt die primäre Datenbankinstanz offline.
Der AlloyDB Omni-Betreiber stuft das Standby-Replikat als neue primäre Datenbankinstanz hoch.
Der AlloyDB Omni-Operator löscht die vorherige primäre Datenbankinstanz.
Der AlloyDB Omni-Betriebsleiter 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
```

Einstellungen für den automatischen Failover-Trigger anpassen

Sie können die Einstellungen verwenden, um automatische Failover für jeden Datenbankcluster anzupassen.

Der AlloyDB Omni-Betriebsleiter führt regelmäßige Systemdiagnosen für die primäre Datenbankinstanz sowie für alle Standby-Replikate durch. Die Standardhäufigkeit für die Prüfungen beträgt 30 Sekunden. Wenn eine Instanz den Triggergrenzwert für den automatischen Failover erreicht, löst der AlloyDB Omni-Betreiber einen automatischen Failover aus.

Der Schwellenwert ist die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor ein Failover ausgelöst wird. Wenn Sie den Zeitraum für die Prüfung oder den Grenzwert ändern möchten, legen Sie im Manifest des Clusters im Feld healthcheckPeriodSeconds und autoFailoverTriggerThreshold Ganzzahlwerte fest:

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Ersetzen Sie Folgendes:

HEALTHCHECK_PERIOD: eine Ganzzahl, die die Anzahl der Sekunden angibt, die zwischen den einzelnen Systemdiagnosen vergehen sollen. Der Standardwert ist 30. Der Mindestwert ist 1 und der maximale Wert 86400 (entspricht einem Tag).
AUTOFAILOVER_TRIGGER_THRESHOLD: eine Ganzzahl für die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor ein Failover ausgelöst wird. Der Standardwert ist 3. Der Mindestwert beträgt 0. Es gibt keinen Maximalwert. Wenn dieses Feld auf 0 gesetzt ist, wird stattdessen der Standardwert 3 verwendet.

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 Replikationsrichtung und die Rollen der primären Datenbankinstanz und des Standby-Replikats umgekehrt. Mit Switchovers haben Sie mehr Kontrolle über den Test Ihrer Notfallwiederherstellung ohne Datenverlust.

Der AlloyDB Omni-Betriebsmodus unterstützt den manuellen Wechsel. Ein Switchover führt zur folgenden Abfolge von Ereignissen:

Der AlloyDB Omni-Betreiber stellt die primäre Datenbankinstanz offline.
Der AlloyDB Omni-Betreiber stuft das Standby-Replikat als neue primäre Datenbankinstanz hoch.
Der AlloyDB Omni-Betreiber schaltet die vorherige primäre Datenbankinstanz in ein Standby-Replikat um.

Switchover durchführen

Führen Sie die folgenden Schritte aus, bevor Sie mit dem Switchover beginnen:

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 Umstellungsressource, z. B. switchover-1.
DB_CLUSTER_NAME: der Name der primären Datenbankinstanz, auf die sich der Umstellungsvorgang bezieht.
STANBDY_REPLICA_NAME: der Name der Datenbankinstanz, die Sie zur neuen primären Instanz machen möchten.

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

Standby-Instanz automatisch reparieren

Wenn eine Standby-Instanz nicht verfügbar ist, stellt der AlloyDB Omni-Betriebstechniker die Instanz wieder her, indem er das alte Standby-Replikat löscht und ein neues Standby-Replikat an dessen Stelle erstellt. Die Standardzeit für die automatische Wiederherstellung beträgt 90 Sekunden.

Durch die automatische Reparatur des Datenbankclusters wird eine fehlerfreie, kontinuierliche Replikation der primären Datenbank aufrechterhalten.

Automatische Reparatur der Instanz deaktivieren

In Datenbankclustern ist standardmäßig die automatische Wiederherstellung einer Standby-Instanz aktiviert.

So deaktivieren Sie automatische Reparaturen:

Legen Sie im Manifest des Clusters enableAutoHeal auf false fest:
```
spec:
  availability:
    enableAutoHeal: false
```

Einstellungen für den Trigger für die automatische Reparatur anpassen

Für jeden Datenbankcluster können Sie die Einstellungen für automatische Reparaturen anpassen.

Der AlloyDB Omni-Operator führt regelmäßige Systemdiagnosen durch, die Sie konfigurieren können. Weitere Informationen finden Sie unter Einstellungen für den automatischen Failover-Trigger anpassen. Wenn ein Standby-Replikat den Triggergrenzwert für die automatische Reparatur erreicht, löst der AlloyDB Omni-Betriebsmitarbeiter eine automatische Reparatur aus.

Der Schwellenwert ist die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor eine Reparatur ausgelöst wird. Wenn Sie den Grenzwert ändern möchten, legen Sie im Manifest des Clusters autoHealTriggerThreshold fest:

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Ersetzen Sie Folgendes:

AUTOHEAL_TRIGGER_THRESHOLD: eine Ganzzahl für die Anzahl der aufeinanderfolgenden Fehlschläge bei der Systemdiagnose, bevor eine Reparatur ausgelöst wird. Der Standardwert ist 3. Der Mindestwert beträgt 2, da es bei Standby-Systemdiagnosen zu vorübergehenden, einmaligen Fehlern kommen kann.

Fehlerbehebung bei der Instanzwiederherstellung

Wenn Sie eine große Anzahl von Datenbankclustern in einem einzigen Kubernetes-Cluster verwenden, kann es (obwohl unwahrscheinlich) passieren, dass die automatische Fehlerbehebung überlastet wird. Wenn du eine Fehlermeldung erhältst, die mit HealthCheckProber: health check for instance failed beginnt und auf eine Zeitüberschreitung oder einen Verbindungsfehler verweist, kannst du versuchen, den Fehler zu beheben, indem du Folgendes tust:

Verringern Sie die Anzahl der Datenbankcluster, die Sie in Ihrem Kubernetes-Cluster verwalten.
Erhöhen Sie den Grenzwert für healthcheckPeriodSeconds, damit die Systemdiagnose seltener ausgeführt wird. Weitere Informationen finden Sie unter Einstellungen für den automatischen Failover-Trigger anpassen.
Erhöhen Sie das CPU-Limit, das Arbeitsspeicherlimit oder beides für den AlloyDB Omni-Operator. Weitere Informationen finden Sie unter Automatische Arbeitsspeicherverwaltung und AlloyDB Omni-Operator-Arbeitsspeicher-Heap-Nutzung analysieren.

Im Folgenden finden Sie Beispiele für Fehler, die durch eine übermäßige automatische Korrektur verursacht werden können. In diesen Beispielen fehlen Umgebungsdetails, die Ihnen helfen können, die Fehlerquelle zu ermitteln, z. B. der Name eines Clusters oder einer IP-Adresse.

HealthCheckProber: health check for instance failed" err="DBSE0005: DBDaemon Client Error. secure dbdaemon connection failed: context deadline exceeded...
HealthCheckProber: health check for instance failed" err="rpc error: code = Code(10303) desc = DBSE0303: Healthcheck: Health check table query failed. dbdaemon/healthCheck: read healthcheck table: timeout...
HealthCheckProber: health check for instance failed" err="rpc error: code = Code(12415) desc = DBSE2415: Postgres: failed to connect to database. dbdaemon/healthCheck: failed to connect...

Ein Standby-Replikat als schreibgeschützte Instanz verwenden

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

Legen Sie im Manifest des Datenbankclusters enableStandbyAsReadReplica auf true fest:
```
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