Nebenversions-Upgrade für AlloyDB Omni in Kubernetes durchführen

Wählen Sie eine Dokumentationsversion aus:

Auf dieser Seite wird beschrieben, wie Sie ein Nebenversions-Upgrade für AlloyDB Omni in Kubernetes durchführen.

Für das Upgrade einer Datenbanknebenversion gibt es zwei Möglichkeiten:

  • Upgrade mit geringer Ausfallzeit (Low Downtime Upgrade, LDTM): In Umgebungen mit hoher Verfügbarkeit aktualisiert der AlloyDB Omni-Operator zuerst Ihre Stand-by-Instanzen. Sobald alle Stand-by-Instanzen erfolgreich aktualisiert wurden, führt der Operator einen Switchover durch und stuft eine der aktualisierten Stand-by-Instanzen zur neuen primären Instanz hoch. Nach dem erfolgreichen Switchover wird die alte primäre Instanz aktualisiert. Dieser sequenzielle Rollout-Prozess sorgt für minimale Ausfallzeiten und dafür, dass die primäre Instanz auf der vorherigen Version aktiv bleibt, bis das Upgrade der Standby-Umgebung vollständig validiert wurde.
  • Gleichzeitiges Upgrade: In Umgebungen ohne Hochverfügbarkeit oder wenn LDTM explizit deaktiviert ist, aktualisiert der AlloyDB Omni-Operator alle Datenbankinstanzen gleichzeitig. Bei dieser Methode kommt es während des Upgrades zu einer Ausfallzeit der Datenbank.

Beschränkungen

Beim Upgrade mit geringen Ausfallzeiten wird jede Stand‑by-Instanz nacheinander aktualisiert und ist während des Upgrades vorübergehend nicht verfügbar.

Damit Ihr Datenbankcluster ein Recovery Point Objective (RPO) von null beibehält und während des Standby-Upgrades kein Datenverlust droht, empfiehlt es sich, mindestens zwei Standby-Instanzen zu haben. Diese Einrichtung fungiert als HA-Konfiguration mit drei Knoten.

Hinweis

  • Wenn Ihr Cluster Hochverfügbarkeit bietet und die AlloyDB Omni-Version älter als 15.7.1 ist, folgen Sie der Anleitung unter Datenbankcluster aktualisieren, bevor Sie dieses Verfahren zum Upgrade der Nebenversion ausführen.
  • Sichern Sie Ihre Daten, um Datenverlust zu vermeiden.
  • Während des Upgrades mit geringer Ausfallzeit wird die HA-Redundanz des Datenbankclusters vorübergehend verringert, während eine Stand‑by-Instanz aktualisiert wird. Die Datenbank bleibt jedoch für Lese- und Schreibvorgänge auf der aktiven primären Instanz verfügbar.

Prozess für das Upgrade von Datenbanknebenversionen mit geringer Ausfallzeit aktivieren

Der Prozess für Upgrades mit geringer Ausfallzeit (Low Downtime Upgrade, LDTM) ist standardmäßig automatisch aktiviert, wenn Ihr Datenbankcluster zwei oder mehr Standby-Instanzen hat.

Wenn Ihr Datenbankcluster nur einen Standby-Cluster hat, müssen Sie LDTM manuell aktivieren, indem Sie dem Datenbankcluster die Annotation dbcluster.dbadmin.goog/enableLDTM=true hinzufügen:

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME
dbcluster.dbadmin.goog/enableLDTM=true

Ersetzen Sie die folgende Variable:

  • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben. Weitere Informationen finden Sie unter AlloyDB Omni in Kubernetes installieren.

AlloyDB Omni-Version aktualisieren

Wenn Sie ein Upgrade von Version 18.3.0 durchführen möchten, aktualisieren Sie die Felder databaseVersion und controlPlaneAgentsVersion in der Manifestdatei des Clusters und wenden Sie die Datei dann noch einmal an.

Im Folgenden sehen Sie den Anfang einer Manifestdatei, in der Version 18.3.0 für databaseVersion und Version 1.8.2 für controlPlaneAgentsVersion angegeben sind:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "DB_VERSION"
    controlPlaneAgentsVersion: "CONTROL_PLANE_AGENTS_VERSION"
    # It is recommended to switch to UBI9 for improved security and
    # compatibility.
    # If you need to stick to Debian, set this field to "Debian".
    databaseImageOSType: "OS_TYPE"
...

Ersetzen Sie die folgende Variable:

  • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben. Weitere Informationen finden Sie unter AlloyDB Omni in Kubernetes installieren.
  • DB_VERSION: die Version der Datenbank, auf die Sie ein Upgrade ausführen.
  • CONTROL_PLANE_AGENTS_VERSION: Die Version der Agents der Steuerungsebene.
  • OS_TYPE: Optional. Das Basisbetriebssystem für das Datenbank-Image. Gültige Werte sind Debian und UBI9. Wenn Sie diesen Wert nicht angeben, wird er vom Operator automatisch auf Debian gesetzt, wenn databaseVersion kleiner als 16.9.0 ist, und auf UBI9, wenn databaseVersion 16.9.0 oder höher ist.

Upgrade-Prozess überwachen

Nachdem Sie die Manifestdatei aktualisiert haben, startet der AlloyDB Omni-Operator den Upgradevorgang. Prüfen Sie den Zustand DBCUpgradeInProgress, um den Upgradevorgang zu überwachen.

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "DBCUpgradeInProgress")'

Ersetzen Sie die folgende Variable:

  • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben. Weitere Informationen finden Sie unter AlloyDB Omni in Kubernetes installieren.

Während der Prozess läuft, ist der Status der Bedingung true. Wenn der Vorgang abgeschlossen ist, ändert sich der Status der Bedingung in false und der Grund wird in UpgradeComplete oder UpgradeFailed aktualisiert.

Fehlerbehebung

Wenn Sie während des Upgrades Fehlermeldungen erhalten, lesen Sie die folgenden Abschnitte:

Fehler vor dem Upgrade

Wenn Sie bei Ihrem Datenbankcluster einen Fehler vor dem Upgrade erhalten, prüfen Sie die Meldung und beheben Sie das Problem entsprechend.

Wenn Sie die Fehlermeldung vor dem Upgrade umgehen möchten, können Sie die Annotation force-upgrade aktivieren.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/force-upgrade=true

Ersetzen Sie die folgende Variable:

  • DB_CLUSTER_NAME: der Name Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben. Weitere Informationen finden Sie unter AlloyDB Omni in Kubernetes installieren.

Nach Abschluss des Upgrades müssen Sie die Anmerkung force-upgrade auf false festlegen.

Upgradefehler

Während des automatischen Upgrades kann es in HA-Umgebungen an mehreren Stellen zu Fehlern kommen. Weitere Informationen zu den einzelnen Fehlerszenarien und den nachfolgenden Aktionen des AlloyDB Omni-Operators finden Sie in der folgenden Tabelle.

Fehlermeldung Beschreibung Erforderliche Nutzeraktionen
Standby instance upgrade succeeded but its replication lag is too high to be promoted to a synchronous standby. Please monitor replication status. Die Stand‑by-Instanz wurde erfolgreich aktualisiert, konnte aber nicht schnell genug mit der primären Instanz synchronisiert werden, um den Schwellenwert für die synchrone Replikation vor dem Zeitüberschreitungszeitraum zu erreichen. Das liegt in der Regel an einem hohen Schreibverkehr auf der primären Instanz.

So ermöglichen Sie die Synchronisierung der Stand‑by-Instanz:

  1. Warten Sie, bis der Schreibtraffic nachlässt, damit die Stand‑by-Instanz nach und nach aufholen kann. Der AlloyDB Omni-Operator stuft es automatisch hoch, sobald es synchronisiert ist.
  2. Optional: Sie können das Catch-up-Zeitlimit erhöhen, indem Sie die Annotation upgrade.alloydbomni.dbadmin.google/standby-catch-up-timeout-in-minutes für Ihren DBCluster festlegen.
All standbys upgrade succeeded but the switchover instance failed to promote an upgraded standby. Ihre Standby-Instanzen wurden erfolgreich aktualisiert, aber der automatische Switchover-Prozess, der darauf ausgelegt ist, eine aktualisierte Standby-Instanz zur primären Instanz zu machen, ist fehlgeschlagen.

Führen Sie die folgenden Schritte aus, um den Switchover-Fehler zu untersuchen und zu beheben:

  1. Prüfen Sie den Status der benutzerdefinierten Switchover-Ressource, um die Ursache zu ermitteln:
    kubectl get switchovers.alloydbomni.dbadmin.goog -n NAMESPACE
  2. Prüfen Sie die Logs und Ereignisse des Switchover-Controllers auf Probleme wie Netzwerkpartitionen oder API-Latenz.
  3. Wählen Sie eine Option unter Primäre und Standby-Instanzen mit unterschiedlichen Nebenversionen korrigieren aus.
Standby instance upgrade failed but rollback to the previous versions succeeded Das Upgrade der Stand-by-Instanz ist fehlgeschlagen, aber der AlloyDB Omni-Operator hat die Instanz erfolgreich auf die vorherige funktionierende Version zurückgesetzt. Da die primäre Instanz nicht geändert wurde, ist Ihre Datenbank in der vorherigen Version weiterhin fehlerfrei.

So diagnostizieren Sie das zugrunde liegende Problem und beheben es:

  1. Ermitteln Sie die Ursache des Upgradefehlers, indem Sie die Logs und Ereignisse des Standby-Pods untersuchen:
    kubectl describe pod -l alloydbomni.dbadmin.goog/instance=[standby-name] -n NAMESPACE
  2. Sobald das Problem behoben ist, z. B. durch Erschöpfung der Knotenressourcen oder Taints, wählen Sie eine Option unter Primäre und Standby-Instanzen mit unterschiedlichen Nebenversionen korrigieren aus.
Standby instance upgrade failed and rollback to the previous versions failed Das Upgrade der Stand-by-Instanz ist fehlgeschlagen und der automatische Versuch des AlloyDB Omni-Operators, ein Rollback auf die vorherige Version durchzuführen, ist ebenfalls fehlgeschlagen. Die Stand-by-Instanz bleibt in einem fehlerhaften/nicht nutzbaren Zustand (wodurch die HA-Redundanz verringert wird), während die primäre Instanz weiterhin Lese-/Schreib-Traffic in der vorherigen Version verarbeitet.

So stellen Sie den Clusterzustand wieder her:

  1. Löschen Sie die fehlerhafte Standby-Instanz, indem Sie die Standby-Anzahl in der DBCluster-Spezifikation auf 0 setzen:
    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE --type=merge -p '{"spec": {"availability": {"numberOfStandbys": 0}}}'
  2. Warten Sie, bis die fehlerhafte Stand‑by-Instanz und ihr Pod vollständig gelöscht wurden.
  3. Skalieren Sie die Anzahl der Standby-Instanzen wieder hoch, um eine neue Standby-Instanz bereitzustellen, die automatisch mit der aktiven primären Instanz synchronisiert wird:
    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE --type=merge -p '{"spec": {"availability": {"numberOfStandbys": 1}}}'

Primäre und Standby-Instanzen mit unterschiedlichen Nebenversionen korrigieren

Wählen Sie eine der folgenden Optionen aus, um dieses Problem zu beheben:

  • Wenn das zugrunde liegende Problem, das zum Upgrade-Fehler geführt hat, behoben wurde, können Sie das Upgrade noch einmal starten. Entfernen Sie die start-time-Annotation des Upgrades aus Ihrem DBCluster, damit der AlloyDB Omni-Operator eine neue Startzeit generiert und den Vorgang noch einmal versucht:

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/start-time-

    Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben. Weitere Informationen finden Sie unter AlloyDB Omni in Kubernetes installieren.

  • Wenn das Problem, das den Upgradefehler verursacht hat, weiterhin besteht und Sie den Cluster lieber in der vorherigen Version behalten möchten, müssen Sie kein Downgrade durchführen. Da das Upgrade während der Standby-Phase fehlgeschlagen ist, wurde Ihr primäres System nie aktualisiert.

    Wenn Sie den Status UpgradeFailed entfernen und zu einem stabilen Zustand ohne Upgrade zurückkehren möchten, aktualisieren Sie die Felder databaseVersion und controlPlaneAgentsVersion des DBCluster-Manifests auf die Versionen, die vor dem Upgradeversuch verwendet wurden, und wenden Sie die Datei dann noch einmal an.