AlloyDB Omni verwalten und überwachen

Einzelserver

AlloyDB Omni protokolliert seine Aktivitäten an zwei Stellen:

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

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

• AlloyDB Omni protokolliert die Installations-, Start- und Herunterfahrvorgänge unter /var/alloydb/logs/alloydb.log.

Informationen zum Prüfen des aktuellen Ausführungsstatus Ihres Servers finden Sie unter Status von AlloyDB Omni prüfen.

Kubernetes

Logdateien des Datenbankclusters suchen

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

1. Definieren Sie eine Umgebungsvariable, die den Namen des Datenbank-Pods enthält.

   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. Das ist derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.

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

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

3. Die Logdateien finden Sie im Verzeichnis /obs/diagnostic/:

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

Monitoring-Dienste auflisten

kubectl get svc -n NAMESPACE | grep monitoring

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

kubectl get svc -n NAMESPACE | grep monitoring

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 die Portweiterleitung von Ihrer lokalen Umgebung zum 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 dem angegebenen Port auf Monitoring-Messwerte zugreifen. 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 Label-Schlü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 das Feld spec der benutzerdefinierten Ressource ServiceMonitor, das den Label-Schlüssel alloydbomni.internal.dbadmin.gdc.goog/task-type und den Port metricsalloydbomni enthält. Die benutzerdefinierte Ressource ServiceMonitor überwacht und erfasst alle Kubernetes-Dienste in allen Namespaces.

Weitere Informationen zur vollständigen ServiceMonitor-Definition finden Sie in der benutzerdefinierten Ressourcendefinition für ServiceMonitor .

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

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

Einzelserver

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-Befehlszeile 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, die Sie zum Upgrade von AlloyDB Omni in Kubernetes ausführen, hängen von der Version von AlloyDB Omni ab, die Sie ausführen, und von der Version, auf die Sie ein Upgrade durchführen.

Aktuelle Versionsnummern ermitteln

Führen Sie den folgenden 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 derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.

• NAMESPACE: Der Kubernetes-Namespace Ihres Datenbankclusters.

Wenn Sie Version 1.0.0 oder höher des AlloyDB Omni-Operators ausführen, 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-Operators 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-Operators ausführen, wird mit diesem Befehl die Versionsnummer des AlloyDB Omni-Operators ausgegeben, der in Ihrem Kubernetes-Cluster ausgeführt wird.

Wenn Sie eine Version von AlloyDB Omni Operator vor 1.0.0 ausführen, können Sie kein In-Place-Upgrade Ihres Datenbankclusters oder des AlloyDB Omni Operators durchführen. Stattdessen müssen Sie der Anleitung unter Upgrade from a pre-1.0.0 AlloyDB Omni Operator folgen.

Andernfalls fahren Sie mit dem nächsten Abschnitt fort.

Zielversionsnummern ermitteln

Wenn Sie eine Version von AlloyDB Omni Operator 1.0.0 oder höher ausführen, hängen die nächsten Schritte von der Version von AlloyDB Omni ab, auf die Sie ein Upgrade durchführen möchten. Dazu müssen Sie die Versionsnummer von AlloyDB Omni kennen.

Die AlloyDB Omni-Versionsnummer besteht aus drei Teilen:

• Die Hauptversionsnummer der PostgreSQL-Kompatibilität
• Die Nebenversionsnummer der PostgreSQL-Kompatibilität
• Die Patchversionsnummer dieses AlloyDB Omni-Release

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 aktualisieren möchten, die eine neuere Version von PostgreSQL unterstützt, müssen Sie den AlloyDB Omni-Operator zusammen mit Ihrem Datenbankcluster aktualisieren. Jede Gruppe von AlloyDB Omni-Releases, die eine bestimmte PostgreSQL-Nebenversion unterstützen, hat eine eigene zugehörige AlloyDB Omni Operator-Versionsnummer, die Sie in den Versionshinweisen für die AlloyDB Omni-Version finden.

Wenn Sie nur auf eine neuere Patchversion von AlloyDB Omni upgraden möchten, können Sie nur Ihren Datenbankcluster upgraden, ohne den AlloyDB Omni-Operator selbst upgraden zu müssen. Sie können direkt zur Anleitung unter Datenbankcluster aktualisieren springen.

Andernfalls fahren Sie mit dem nächsten Abschnitt fort.

AlloyDB Omni-Operator aktualisieren

So aktualisieren Sie den AlloyDB Omni-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-Operators, auf die Sie aktualisieren, 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 benutzerdefinierten Ressourcendefinitionen des AlloyDB Omni-Operators an:

   kubectl apply -f alloydbomni-operator/crds

4. Aktualisieren Sie das Helm-Diagramm für den AlloyDB Omni-Operator:

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

Wenn Sie das Upgrade Ihres AlloyDB Omni-Operators durchführen möchten, indem Sie sowohl Ihr Kubernetes-Manifest als auch Ihren Datenbankcluster aktualisieren, folgen Sie der Anleitung im nächsten Abschnitt, sobald Sie die vorherigen Schritte abgeschlossen haben.

Datenbankcluster upgraden

Um Ihren Datenbankcluster zu aktualisieren, aktualisieren Sie die folgenden Felder im Abschnitt spec des Manifests, das ihn definiert:

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

• Wenn Sie auch den AlloyDB Omni-Operator aktualisiert haben, legen Sie controlPlaneAgentsVersion auf die vollständige Versionsnummer des AlloyDB Omni-Operators fest, den Sie aktualisiert haben.

Wenn Sie nur die Patch-Version 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. Achten Sie in diesem Fall darauf, dass Sie die zusätzlichen Schritte unter AlloyDB Omni-Operator aktualisieren ausgeführt haben.

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

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

Wenn Sie in diesem Beispiel den Datenbankcluster aktualisieren möchten, damit er mit AlloyDB Omni-Version 15.5.3 ausgeführt wird, ändern Sie databaseVersion: 15.5.2 in databaseVersion: 15.5.3.

Upgrade von einem AlloyDB Omni-Operator vor Version 1.0.0

Wenn Sie eine Version des AlloyDB Omni-Operators vor 1.0.0 verwenden, müssen Sie zum Aktualisieren einer Kubernetes-basierten AlloyDB Omni-Installation den AlloyDB Omni-Operator deinstallieren und dann neu installieren, nachdem Sie Ihre Daten gesichert haben. Gehen Sie so vor:

1. Alle Datenbankcluster auflisten:

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

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

3. Deinstallieren Sie den AlloyDB Omni-Operator. Dazu gehört das Löschen aller Ihrer Datenbankcluster.

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

5. Datenbankcluster neu erstellen Sie können dieselben Manifestdateien verwenden, die Sie bereits beim Erstellen Ihrer Datenbankcluster verwendet haben. Möglicherweise müssen Sie die Dateien aktualisieren, um API-Änderungen zu berücksichtigen, die mit Version 1.0.0 des AlloyDB Omni-Operators eingeführt wurden. Dazu gehört beispielsweise 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.

Einzelserver

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

sudo alloydb database-server uninstall

Ihr Datenverzeichnis verbleibt nach der Deinstallation von AlloyDB Omni in Ihrem Dateisystem. 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 Ihren Datenbankcluster löschen möchten, legen Sie isDeleted im Manifest auf true fest. Dazu können Sie den folgenden Befehl verwenden.

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 derselbe Datenbankclustername, den Sie beim Erstellen des Clusters angegeben haben.

AlloyDB Omni-Operator deinstallieren

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

1. Löschen Sie alle Ihre 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, benutzerdefinierte Ressourcendefinitionen und Namespaces, die mit dem AlloyDB Omni Kubernetes-Operator zusammenhängen:

   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