Hochverfügbarkeit in Kubernetes verwalten

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie Hochverfügbarkeit (High Availability, HA) für Ihren Kubernetes-basierten AlloyDB Omni-Datenbankcluster aktivieren und testen. In diesem Dokument wird davon ausgegangen, dass Sie grundlegende Kenntnisse im Anwenden von Kubernetes-Manifestdateien und in der Verwendung des kubectl-Befehlszeilentools haben.

Übersicht

Sie aktivieren die Hochverfügbarkeit in Ihrem Datenbankcluster, indem Sie den AlloyDB Omni Kubernetes-Operator so konfigurieren, dass Stand-by-Replikate Ihrer primären Datenbankinstanz erstellt werden. Der AlloyDB Omni-Operator konfiguriert Ihren Datenbankcluster so, dass die Daten auf diesem Replikat kontinuierlich aktualisiert werden und alle Datenänderungen in Ihrer primären Instanz übernommen werden.

Hochverfügbarkeit aktivieren

Bevor Sie die Hochverfügbarkeit in Ihrem Datenbankcluster aktivieren, muss Ihr Kubernetes-Cluster Folgendes enthalten:

  • Speicher für zwei vollständige Kopien Ihrer Daten

  • Rechenressourcen für zwei parallel ausgeführte Datenbankinstanzen

So aktivieren Sie die Hochverfügbarkeit:

  1. Ändern Sie das Manifest des Datenbankclusters so, dass es unter dem Abschnitt spec einen Abschnitt availability enthält. In diesem Abschnitt wird der Parameter numberOfStandbys verwendet, um die Anzahl der hinzuzufügenden Stand-by-Instanzen anzugeben.

    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 sich nicht sicher sind, wie viele Stand-bys Sie benötigen, beginnen Sie mit dem Wert 1 oder 2.

  2. Wenden Sie das Manifest noch einmal an.

Hochverfügbarkeit deaktivieren

So deaktivieren Sie die Hochverfügbarkeit:

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

    spec:
  availability:
    numberOfStandbys: 0

  2. Wenden Sie das Manifest noch einmal an.

Hochverfügbarkeit in einem Datenbankcluster prüfen

Wenn Sie den Status der Hochverfügbarkeit in einem Datenbankcluster prüfen möchten, sehen Sie sich den Status HAReady an. Wenn der Status von HAReady True ist, ist die Hochverfügbarkeit aktiviert und funktioniert im Cluster. Wenn der Status False ist, ist die Hochverfügbarkeit zwar aktiviert, aber noch nicht bereit, da sie gerade eingerichtet wird.

Wenn Sie den Status HAReady mit dem kubectl-Befehlszeilentool prüfen möchten, führen Sie den folgenden Befehl aus:

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 Stand-by-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 Stand-by-Instanz durch. Die folgenden Parameter bestimmen, wann ein automatisches Failover gestartet wird:

  • Die Zeit zwischen den Systemdiagnosen (Standardwert: 30 Sekunden).

  • Die Anzahl der aufeinanderfolgenden fehlgeschlagenen Systemdiagnosen (Standardwert ist 3).

Ein automatisches Failover wird nach der angegebenen Anzahl aufeinanderfolgender fehlgeschlagener Systemdiagnosen mit der angegebenen Zeit zwischen den einzelnen fehlgeschlagenen Systemdiagnosen gestartet. Wenn die Standardwerte beibehalten werden, erfolgt ein automatisches Failover nach drei aufeinanderfolgenden fehlgeschlagenen Systemdiagnosen, die jeweils 30 Sekunden auseinanderliegen.

Ein manuelles Failover ist eine gute Option, wenn nach einem unerwarteten Fehler eine schnelle Wiederherstellung sowie eine geringe Ausfallzeit gewünscht sind.

Der AlloyDB Omni-Operator unterstützt sowohl automatische als auch 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 Stand-by-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 Stand-by-Replikat.

Automatisches Failover deaktivieren

Automatische Failover sind in Datenbankclustern standardmäßig aktiviert.

So deaktivieren Sie das automatische 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 regelmäßige Systemdiagnosen für die primäre Datenbankinstanz sowie für alle Stand-by-Replikate durch. Die Standardhäufigkeit für Health Checks beträgt 30 Sekunden. Wenn eine Instanz den Grenzwert für den automatischen Failover erreicht, löst der AlloyDB Omni-Operator einen automatischen Failover aus.

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

spec:
  availability:
    healthcheckPeriodSeconds: HEALTHCHECK_PERIOD
    autoFailoverTriggerThreshold: AUTOFAILOVER_TRIGGER_THRESHOLD

Ersetzen Sie Folgendes:

  • HEALTHCHECK_PERIOD: Die Anzahl der Sekunden als Ganzzahlwert, die zwischen den einzelnen Systemdiagnosen gewartet werden soll. Der Standardwert ist 30. Der Mindestwert ist 1 und der Höchstwert ist 86400 (entspricht einem Tag).

  • AUTOFAILOVER_TRIGGER_THRESHOLD: Ein Ganzzahlwert für die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor ein Failover ausgelöst wird. Der Standardwert ist 3. Der Mindestwert ist 0. Es gibt keinen Höchstwert. Wenn dieses Feld auf 0 gesetzt ist, wird stattdessen der Standardwert 3 verwendet.

Manuelles Failover auslösen

Wenn Sie ein manuelles Failover auslösen möchten, erstellen und wenden Sie ein Manifest für eine neue Failover-Ressource 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 ausgeführt werden soll.

Wenn Sie das Failover überwachen möchten, führen Sie 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 Stand-by-Instanz finden Sie im nächsten Abschnitt.

Switchover zur Stand-by-Instanz durchführen

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 Stand-by-Replikats getauscht werden müssen.

Nach Abschluss des Switchovers werden die Richtung der Replikation und die Rollen der primären Datenbankinstanz sowie des Stand-by-Replikats umgekehrt. Mit Switchovers haben Sie mehr Kontrolle über das Testen Ihrer Notfallwiederherstellungseinrichtung ohne Datenverlust.

Der AlloyDB Omni-Operator unterstützt manuelles Switchover. Ein Switchover führt zu der folgenden Ereignisabfolge:

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

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

  3. Der AlloyDB Omni-Operator ändert die vorherige primäre Datenbankinstanz in ein Stand-by-Replikat.

Switchover durchführen

Bevor Sie ein Switchover starten, führen Sie die folgenden Schritte aus:

Um ein Switchover durchzuführen, 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: STANDBY_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 der Switchover-Vorgang angewendet wird.

  • STANDBY_REPLICA_NAME: Der Name der Datenbankinstanz, die Sie zur neuen primären Instanz hochstufen möchten.

    Führen Sie den folgenden Befehl aus, um den Namen des Stand-by-Replikats zu ermitteln:

    kubectl get instances.alloydbomni.internal.dbadmin.goog

Stand-by-Instanz automatisch reparieren

Wenn eine Stand-by-Instanz nicht mehr verfügbar ist, behebt der AlloyDB Omni-Operator das Problem, indem er das alte Stand-by-Replikat löscht und ein neues Stand-by-Replikat an dessen Stelle erstellt. Die Standardzeit zum Auslösen einer automatischen Reparatur beträgt 90 Sekunden.

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

Automatische Reparatur der Instanz deaktivieren

Standardmäßig ist die automatische Reparatur einer Stand-by-Instanz in Datenbankclustern aktiviert.

So deaktivieren Sie die automatische Reparatur:

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

    spec:
  availability:
    enableAutoHeal: false

Triggereinstellungen für die automatische Reparatur anpassen

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

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

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

spec:
  availability:
    autoHealTriggerThreshold: AUTOHEAL_TRIGGER_THRESHOLD

Ersetzen Sie Folgendes:

  • AUTOHEAL_TRIGGER_THRESHOLD: Ein Ganzzahlwert für die Anzahl der aufeinanderfolgenden Fehler bei der Systemdiagnose, bevor eine Reparatur ausgelöst wird. Der Standardwert ist 5. Der Mindestwert ist 2, da bei Systemdiagnosen für Stand-by-Instanzen vorübergehende, einmalige Fehler auftreten können.

Fehlerbehebung bei der Instanzreparatur

Wenn Sie eine große Anzahl von Datenbankclustern in einem einzelnen Kubernetes-Cluster verwenden oder wenn Ihre Datenbankcluster unterversorgt sind, kann die automatische Reparatur zu einer Nichtverfügbarkeit des AlloyDB Omni-Operators oder der Datenbankcluster führen. Wenn Sie einen Fehler erhalten, der mit HealthCheckProber: health check for instance failed beginnt und auf eine Zeitüberschreitung oder einen Verbindungsfehler verweist, versuchen Sie die folgenden empfohlenen Korrekturen:

Im Folgenden finden Sie Beispiele für Fehler, die durch eine übermäßige automatische Reparatur verursacht werden können. In diesen Beispielen werden Umgebungsdetails ausgelassen, mit denen Sie die Fehlerquelle identifizieren können, z. B. der Name eines Clusters oder eine 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...

Stand-by-Replikat als schreibgeschützte Instanz verwenden

So verwenden Sie ein Stand-by-Replikat als schreibgeschützte Instanz:

  1. Setzen Sie enableStandbyAsReadReplica im Manifest des Datenbankclusters auf true:

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