AlloyDB Omni verwalten und überwachen

Auf dieser Seite wird beschrieben, wie Sie AlloyDB Omni-Nutzerrollen verwalten, die Aktivitäten Ihres AlloyDB Omni-Servers überwachen und Ihre AlloyDB Omni-Installation aktualisieren oder entfernen.

Nutzerrollen verwalten

AlloyDB Omni verwendet dieselben vordefinierten PostgreSQL-Nutzerrollen wie AlloyDB, mit folgenden Unterschieden:

• In AlloyDB Omni gibt es keine alloydbiamuser-Rolle.

• AlloyDB Omni enthält eine Superuser-Rolle namens alloydbadmin.

Wie bei AlloyDB empfiehlt es sich, beim Einrichten einer Datenbank die folgenden Schritte auszuführen:

1. Definieren oder importieren Sie Ihre Datenbanken mit der Nutzerrolle postgres. Bei einer neuen Installation hat diese Rolle Berechtigungen zum Erstellen von Datenbanken und Rollen und kein Passwort.

2. Erstellen Sie neue Nutzerrollen mit der richtigen Zugriffsebene auf die Tabellen Ihrer Anwendung. Verwenden Sie dazu wieder die Nutzerrolle postgres.

3. Konfigurieren Sie Ihre Anwendung so, dass eine Verbindung zur Datenbank mit diesen neuen Rollen mit eingeschränktem Zugriff hergestellt wird.

Sie können beliebig viele neue Nutzerrollen erstellen und definieren. Ändern oder löschen Sie keine der Nutzerrollen, die mit AlloyDB Omni ausgeliefert werden.

Weitere Informationen finden Sie unter AlloyDB-Nutzerrollen verwalten.

AlloyDB Omni überwachen

Das Überwachen Ihrer AlloyDB Omni-Installation bedeutet, die Protokolldateien zu lesen und zu analysieren.

Für AlloyDB Omni, das auf Kubernetes ausgeführt wird, sind auch einige grundlegende Messwerte als Prometheus-Endpunkte verfügbar. Eine Liste der verfügbaren Messwerte finden Sie unter AlloyDB Omni-Messwerte.

Ein Server

AlloyDB Omni protokolliert seine Aktivitäten an zwei Stellen:

• AlloyDB Omni protokolliert Datenbankaktivitäten unter data/log/postgres, relativ zum Verzeichnis, das Sie in der Konfigurationsdatei dataplane.conf definiert haben.

  Sie können den Namen und das Format dieser Protokolldatei über die verschiedenen log_*-Direktive anpassen, die in /var/alloydb/config/postgresql.conf definiert sind. Weitere Informationen finden Sie unter Fehlerberichte und ‑protokollierung.

• AlloyDB Omni protokolliert die Installation, den Start und das Herunterfahren unter /var/alloydb/logs/alloydb.log.

Wie Sie den aktuellen Status Ihres Servers prüfen, erfahren Sie unter Status von AlloyDB Omni prüfen.

Kubernetes

Protokolldateien des Datenbankclusters finden

Sie finden die postgresql.audit- und postgresql.log-Dateien im Dateisystem des Datenbank-Pods. So greifen Sie auf diese Dateien zu:

1. Definieren Sie eine Umgebungsvariable mit dem Namen des Datenbank-Pods.

   export DB_POD=`kubectl get pod -l alloydbomni.internal.dbadmin.goog/dbcluster=DB_CLUSTER_NAME,alloydbomni.internal.dbadmin.goog/task-type=database -o jsonpath='{.items[0].metadata.name}'`

   Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters. Dies ist der Name des Datenbankclusters, den Sie beim Erstellen angegeben haben.

2. Führen Sie eine Shell auf dem Datenbank-Pod als Root aus.

   kubectl exec ${DB_POD} -it -- /bin/bash

3. Suchen Sie die Logdateien im Verzeichnis /obs/diagnostic/:

   • /obs/diagnostic/postgresql.audit
   • /obs/diagnostic/postgresql.log

Überwachungsdienste auflisten

v1.0

Wenn Sie einen Datenbankcluster erstellen, erstellt AlloyDB Omni für jeden Instanz-CR des Datenbankclusters im selben Namespace den folgenden Monitoring-Dienst:

al-INSTANCE_NAME-monitoring-system

Führen Sie den folgenden Befehl aus, um die Überwachungsdienste aufzulisten.

kubectl get svc -n NAMESPACE | grep monitoring

Ersetzen Sie NAMESPACE durch einen Namespace, zu dem Ihr Cluster gehört.

Die folgende Beispielantwort zeigt die Dienste al-1060-dbc-monitoring-system, al-3de6-dbc-monitoring-system und al-4bc0-dbc-monitoring-system. Jedem Dienst entspricht eine Instanz.

al-1060-dbc-monitoring-system   ClusterIP   10.0.15.227   <none>        9187/TCP   7d20h
al-3de6-dbc-monitoring-system   ClusterIP   10.0.5.205    <none>        9187/TCP   7d19h
al-4bc0-dbc-monitoring-system   ClusterIP   10.0.15.92    <none>        9187/TCP   7d19h

Version < 1.0

Wenn Sie einen Datenbankcluster erstellen, erstellt AlloyDB Omni die folgenden Monitoring-Dienste im selben Namespace wie der Datenbankcluster:

• DB_CLUSTER-monitoring-db

• DB_CLUSTER-monitoring-system

Führen Sie den folgenden Befehl aus, um die Überwachungsdienste aufzulisten.

kubectl get svc -n NAMESPACE | grep monitoring

Ersetzen Sie NAMESPACE durch einen Namespace, zu dem Ihr Cluster gehört.

Die folgende Beispielantwort zeigt den al-2953-dbcluster-foo7-monitoring-system- und den al-2953-dbcluster-foo7-monitoring-db-Dienst.

al-2953-dbcluster-foo7-monitoring-db           ClusterIP   10.36.3.243    <none>        9187/TCP   44m
al-2953-dbcluster-foo7-monitoring-system       ClusterIP   10.36.7.72     <none>        9187/TCP   44m

Prometheus-Messwerte über die Befehlszeile aufrufen

Der Port 9187 wird für alle Monitoring-Dienste als metricsalloydbomni bezeichnet.

1. Richten Sie eine Portweiterleitung von Ihrer lokalen Umgebung an den Monitoring-Dienst ein.

   kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
   

   Ersetzen Sie Folgendes:

   • MONITORING_SERVICE: Der Name des Monitoring-Dienstes, den Sie weiterleiten möchten, z. B. al-1060-dbc-monitoring-system.

   • NAMESPACE: Der Namespace, zu dem Ihr Cluster gehört.

   • MONITORING_METRICS_PORT: Ein lokal verfügbarer TCP-Port.

   Die folgende Antwort zeigt, dass die Dienste weitergeleitet werden.

   Forwarding from 127.0.0.1:9187 -> 9187
   Forwarding from [::1]:9187 -> 9187
   

2. Während der vorherige Befehl ausgeführt wird, können Sie über HTTP auf den angegebenen Port zugreifen, um Messwerte zu überwachen. Mit curl können Sie beispielsweise alle Messwerte als Nur-Text anzeigen lassen:

   curl http://localhost:MONITORING_METRICS_PORT/metrics
   

Messwerte mit der Prometheus API ansehen

Der Labelschlüssel alloydbomni.internal.dbadmin.goog/task-type und der Port metricsalloydbomni sind standardmäßig für alle Monitoring-Dienste in AlloyDB Omni verfügbar. Sie können sie zusammen mit einer einzelnen benutzerdefinierten serviceMonitor-Ressource verwenden, um alle Dienste für alle Namespaces in Ihrem Datenbankcluster auszuwählen.

Weitere Informationen zur Verwendung der Prometheus API finden Sie in der Prometheus Operator-Dokumentation.

Das folgende Beispiel zeigt ein spec-Feld der benutzerdefinierten Ressource serviceMonitor mit dem Labelschlüssel alloydbomni.internal.dbadmin.gdc.goog/task-type und dem Port metricsalloydbomni. Die benutzerdefinierte Ressource serviceMonitor überwacht und erfasst alle Kubernetes-Dienste in allen Namespaces.

Weitere Informationen zur vollständigen Definition von ServiceMonitor finden Sie in der ServiceMonitor-Benutzerdefinierten Ressourcendefinition .

v1.0

    spec:
      selector:
        matchLabels:
          alloydbomni.internal.dbadmin.goog/task-type: monitoring
      namespaceSelector:
        any: true
      endpoints:
        - port: metricsalloydbomni

Version < 1.0

    spec:
      selector:
        matchExpressions:
        - key: alloydbomni.internal.dbadmin.gdc.goog/task-type
          operator: Exists
          values: []
      namespaceSelector:
        any: true
      endpoints:
      - port: metricsalloydbomni

AlloyDB Omni upgraden

Achtung :Wie bei jedem Datenbankupgrade sollten Sie Ihre Daten vor dem Fortfahren sichern. Mit dem Befehl pg_dumpall können Sie Ihre Daten einmalig lokal exportieren.

Ein Server

Diese Anleitung gilt nur für AlloyDB Omni Version 15.2.0 und höher.

Hinweise

Auf Ihrem Computer muss Version 1.2 oder höher der AlloyDB Omni CLI installiert sein.

Führen Sie das Upgrade aus

Führen Sie den folgenden Befehl aus, um Ihre AlloyDB Omni-Installation zu aktualisieren:

sudo alloydb database-server upgrade

Kubernetes

Die Schritte zum Upgrade von AlloyDB Omni in Kubernetes hängen von der Version von AlloyDB Omni ab, die Sie verwenden, und von der Version, auf die Sie ein Upgrade durchführen.

Aktuelle Versionsnummern ermitteln

Führen Sie diesen Befehl aus, um die Version von AlloyDB Omni zu prüfen, die von Ihrem Datenbankcluster verwendet wird:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentDatabaseVersion}'

Ersetzen Sie Folgendes:

• DB_CLUSTER_NAME: Der Name Ihres Datenbankclusters. Das ist der Name des Datenbankclusters, den Sie beim Erstellen angegeben haben.

• NAMESPACE: den Kubernetes-Namespace Ihres Datenbankclusters.

Wenn Sie Version 1.0.0 oder höher des AlloyDB Omni-Betriebsmanagers verwenden, wird mit diesem Befehl die Version von AlloyDB Omni ausgegeben, die von Ihrem Datenbankcluster verwendet wird.

Führen Sie den folgenden Befehl aus, um die Version des AlloyDB Omni-Betriebsmanagers zu prüfen, der in Ihrem Kubernetes-Cluster installiert ist:

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentControlPlaneAgentsVersion}'

Wenn Sie Version 1.0.0 oder höher des AlloyDB Omni-Betriebsmanagers verwenden, gibt dieser Befehl die Versionsnummer des AlloyDB Omni-Betriebsmanagers aus, der auf Ihrem Kubernetes-Cluster ausgeführt wird.

Wenn Sie eine Version des AlloyDB Omni-Betriebssystems vor 1.0.0 ausführen, können Sie keinen vor Ort ausgeführten Upgrade Ihres Datenbankclusters oder des AlloyDB Omni-Betriebssystems durchführen. Stattdessen müssen Sie der Anleitung unter Upgrade von einem AlloyDB Omni-Betriebssystem vor Version 1.0.0 folgen.

Andernfalls fahren Sie mit dem nächsten Abschnitt fort.

Zielversionsnummern ermitteln

Wenn Sie die Version 1.0.0 oder höher des AlloyDB Omni-Betriebsmanagers verwenden, hängen die nächsten Schritte von der Version von AlloyDB Omni ab, auf die Sie ein Upgrade durchführen möchten. Dazu ist es wiederum erforderlich, die AlloyDB Omni-Versionsnummer zu kennen.

Die AlloyDB Omni-Versionsnummer besteht aus drei Teilen:

• Die Hauptversionsnummer der PostgreSQL-Kompatibilität
• Die Minorversion der PostgreSQL-Kompatibilität
• Die Patchversion dieser AlloyDB Omni-Version

Beispiel: AlloyDB Omni Version 15.5.2 ist die Patchversion 2 von AlloyDB Omni, die PostgreSQL Version 15.5 unterstützt.

Wenn Sie auf eine Version von AlloyDB Omni umstellen möchten, die eine neuere Version von PostgreSQL unterstützt, müssen Sie sowohl den AlloyDB Omni-Betriebsmechanismus als auch Ihren Datenbankcluster aktualisieren. Jede Gruppe von AlloyDB Omni-Releases, die eine bestimmte PostgreSQL-Nebenversion unterstützt, hat eine eigene AlloyDB Omni-Betriebssystemversion. Sie finden sie in den Releasenotes für die AlloyDB Omni-Version.

Wenn Sie nur auf eine neuere Patchversion von AlloyDB Omni umstellen möchten, können Sie nur Ihren Datenbankcluster aktualisieren. Der AlloyDB Omni-Betriebsmechanismus selbst muss nicht aktualisiert werden. Sie können mit der Anleitung unter Datenbankcluster aktualisieren fortfahren.

Andernfalls fahren Sie mit dem nächsten Abschnitt fort.

AlloyDB Omni-Operator aktualisieren

So aktualisieren Sie den AlloyDB Omni-Betriebssystem-Operator:

1. Definieren Sie die erforderlichen Umgebungsvariablen:

   export GCS_BUCKET=alloydb-omni-operator
   export OPERATOR_VERSION=OPERATOR_VERSION
   export HELM_PATH=$OPERATOR_VERSION/alloydbomni-operator-$OPERATOR_VERSION.tgz

   Ersetzen Sie OPERATOR_VERSION durch die Version des AlloyDB Omni-Betriebssystems, auf die Sie umstellen, z. B. 1.1.0.

2. Laden Sie den neueren AlloyDB Omni-Operator herunter:

   gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
   tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz

3. Wenden Sie die neueren Definitionen für benutzerdefinierte AlloyDB Omni-Operator-Ressourcen an:

   kubectl apply -f alloydbomni-operator/crds

4. Führen Sie ein Upgrade des Helm-Diagramms für den AlloyDB Omni-Operator durch:

   helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \
   --namespace alloydb-omni-system \
   --atomic \
   --timeout 5m

Wenn Sie nach dem Upgrade des AlloyDB Omni-Betreibers sowohl Ihr Kubernetes-Manifest als auch Ihren Datenbankcluster aktualisieren möchten, folgen Sie der Anleitung im nächsten Abschnitt direkt nach Abschluss der vorherigen Schritte.

Datenbankcluster aktualisieren

Aktualisieren Sie zum Upgraden Ihres Datenbankclusters die folgenden Felder im Abschnitt spec des Manifests, das ihn definiert:

• Legen Sie für databaseVersion die vollständige Versionsnummer von AlloyDB Omni fest, auf die Sie diesen Datenbankcluster aktualisieren möchten.

• Wenn Sie auch das Upgrade für AlloyDB Omni Operator durchgeführt haben, setzen Sie controlPlaneAgentsVersion auf die vollständige Versionsnummer des AlloyDB Omni Operator, für den Sie das Upgrade durchgeführt haben.

Wenn Sie nur die Patchversion von AlloyDB Omni aktualisieren, z. B. databaseVersion von 15.5.1 auf 15.5.2, ist dieser Schritt alles, was Sie tun müssen.

Wenn Sie die Nebenversion der PostgreSQL-Kompatibilität aktualisieren, z. B. databaseVersion von 15.4.1 auf 15.5.2, müssen Sie auch controlPlaneAgentsVersion aktualisieren. In diesem Fall müssen Sie die zusätzlichen Schritte unter AlloyDB Omni-Betriebssystem aktualisieren ausführen.

Im folgenden Manifestauszug wird beispielsweise ein Datenbankcluster mit der AlloyDB Omni-Betriebsversion 15.5.2 und der AlloyDB Omni-Betriebsversion 1.0.0 definiert:

apiVersion: alloydbomni.dbadmin.goog/v1 
kind: DBCluster
metadata:
  name: dbcluster-sample
spec:
  databaseVersion: 15.5.2
  controlPlaneAgentsVersion: 1.0.0

In diesem Beispiel ändern Sie databaseVersion: 15.5.2 in databaseVersion: 15.5.3, um den Datenbankcluster auf die Ausführung der AlloyDB Omni-Version 15.5.3 umzustellen.

Upgrade von einem AlloyDB Omni-Operator vor Version 1.0.0

Wenn Sie eine Version des AlloyDB Omni-Operators verwenden, die älter als 1.0.0 ist, müssen Sie den AlloyDB Omni-Operator nach dem Sichern Ihrer Daten deinstallieren und dann wieder installieren, um eine Kubernetes-basierte AlloyDB Omni-Installation zu aktualisieren. Gehen Sie so vor:

1. Listen Sie alle Ihre Datenbankcluster auf:

   kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

2. Verwenden Sie für jeden Datenbankcluster den Befehl pg_dumpall, um alle Daten zu exportieren.

   Warnung :Überspringen Sie diesen Schritt nicht. Wenn Sie Ihre Daten nicht exportieren, werden sie im nächsten Schritt unwiederbringlich gelöscht.

3. Deinstallieren Sie den AlloyDB Omni-Operator. Dabei werden auch alle Ihre Datenbankcluster gelöscht.

4. Installieren Sie den AlloyDB Omni-Operator neu. Sie können dieselben Befehle verwenden, die Sie zur Installation der vorherigen Version des AlloyDB Omni-Betriebssystems verwendet haben. Sie müssen keine neue Versionsnummer angeben.

5. Erstellen Sie Ihre Datenbankcluster neu. Sie können dieselben Manifestdateien anpassen, die Sie beim Erstellen Ihrer Datenbankcluster verwendet haben. Möglicherweise müssen Sie die Dateien aktualisieren, um API-Änderungen widerzuspiegeln, die in Version 1.0.0 des AlloyDB Omni-Betreibers eingeführt wurden, z. B. das Attribut databaseVersion, das das ältere Attribut version ersetzt.

6. Verwenden Sie pg_restore oder den Befehl \i in psql, um die zuvor exportierten Daten in die neu erstellten Cluster zu importieren.

Rollback eines Upgrade durchführen

Diese Anleitung gilt nur für AlloyDB Omni-Versionen 15.2.1 bis 15.5.2. Sie gelten nicht für Kubernetes-basierte Bereitstellungen von AlloyDB Omni.

Führen Sie diesen Befehl aus, um AlloyDB Omni auf die zuvor installierte Version zurückzusetzen:

sudo alloydb database-server rollback

Achtung: Wenn Sie die Technologievorschau für parametrisierte sichere Ansichten in AlloyDB Omni Version 15.5.0 oder höher installiert haben, müssen Sie einige zusätzliche Schritte ausführen, bevor Sie ein Rollback ausführen.

AlloyDB Omni deinstallieren

Ein Server

Führen Sie den folgenden Befehl aus, um AlloyDB Omni zu deinstallieren:

sudo alloydb database-server uninstall

Das Datenverzeichnis bleibt nach der Deinstallation von AlloyDB Omni in Ihrem Dateisystem erhalten. Sie können dieses Verzeichnis verschieben, archivieren oder löschen, je nachdem, ob und wie Sie Ihre Daten nach der Deinstallation von AlloyDB Omni aufbewahren möchten.

Kubernetes

Datenbankcluster löschen

Wenn Sie den Datenbankcluster löschen möchten, setzen Sie im Manifest isDeleted auf true. Führen Sie dazu den folgenden Befehl aus.

Achtung: Wenn Sie den folgenden Befehl ausführen, werden alle im angegebenen Datenbankcluster gespeicherten Daten endgültig gelöscht.

kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge

Ersetzen Sie DB_CLUSTER_NAME durch den Namen Ihres Datenbankclusters. Das ist der Name des Datenbankclusters, den Sie beim Erstellen angegeben haben.

AlloyDB Omni-Operator deinstallieren

Achtung: Wenn Sie diese Schritte ausführen, werden alle AlloyDB Omni-Datenbanken endgültig aus Ihrem Kubernetes-Cluster gelöscht.

So deinstallieren Sie den AlloyDB Omni Kubernetes-Operator aus Ihrem Kubernetes-Cluster:

1. Löschen Sie alle Datenbankcluster:

   for ns in $(kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces -o=jsonpath='{range .items[*]}{.metadata.namespace}{"\n"}{end}'); do
   for cr in $(kubectl get dbclusters.alloydbomni.dbadmin.goog -n $ns -o=jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}'); do
   kubectl patch dbclusters.alloydbomni.dbadmin.goog $cr -n $ns --type=merge -p '{"spec":{"isDeleted":true}}'
   done
   done

2. Warten Sie, bis der AlloyDB Omni Kubernetes-Operator alle Ihre Datenbankcluster gelöscht hat. Mit dem folgenden Befehl können Sie prüfen, ob noch Datenbankressourcen vorhanden sind:

   kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces

3. Löschen Sie andere Ressourcen, die vom AlloyDB Omni Kubernetes-Operator erstellt wurden:

   kubectl delete failovers.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete restores.alloydbomni.dbadmin.goog --all --all-namespaces
   kubectl delete switchovers.alloydbomni.dbadmin.goog --all --all-namespaces

4. Deinstallieren Sie den AlloyDB Omni Kubernetes-Operator:

   helm uninstall alloydbomni-operator --namespace alloydb-omni-system

5. Bereinigen Sie Secrets, Beschreibungen benutzerdefinierter Ressourcen und Namespaces, die sich auf den AlloyDB Omni Kubernetes-Operator beziehen:

   kubectl delete certificate -n alloydb-omni-system --all
   kubectl get secrets --all-namespaces -o custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,ANNOTATION:.metadata.annotations.cert-manager\.io/issuer-name | grep -E 'alloydbomni|dbs-al' | awk '{print $1 " " $2}' | xargs -n 2 kubectl delete secret -n
   kubectl delete crd -l alloydb-omni=true
   kubectl delete ns alloydb-omni-system

Größe des Kubernetes-basierten Datenbankclusters ändern

Wenn Sie die CPU-, Arbeitsspeicher- oder Speicherkapazität Ihres Kubernetes-basierten Datenbankclusters ändern möchten, aktualisieren Sie das Feld resources der Manifeste, die den Pod definieren. Der AlloyDB Omni-Operator wendet die neuen Spezifikationen sofort auf Ihren Datenbank-Pod an.

Weitere Informationen zur Syntax des AlloyDB Omni-Betreibermanifests finden Sie unter Datenbankcluster erstellen.

Für die Änderung der Ressourcen eines laufenden Datenbankclusters gelten die folgenden Einschränkungen:

• Sie können die Größe eines Laufwerks nur erhöhen, wenn die angegebene storageClass die Volumeerweiterung unterstützt.
• Sie können die Größe eines Laufwerks nicht verringern.