Nutzerrollen verwalten
AlloyDB Omni verwendet dieselben vordefinierten PostgreSQL-Nutzerrollen wie AlloyDB, mit den folgenden Unterschieden:
AlloyDB Omni enthält eine Superuser-Rolle mit dem Namen
alloydbadmin
und eine Rolle ohne Superuser-Berechtigungen mit dem Namenalloydbmetadata
.Der
postgres
-Standardnutzer hat eine Superuser-Rolle.Alle anderen vordefinierten Nutzerrollen haben keine Berechtigungen. Sie sind für die zukünftige Verwendung reserviert.
Wie bei AlloyDB empfiehlt es sich, beim Einrichten einer Datenbank so vorzugehen:
Definieren oder importieren Sie Ihre Datenbanken mit der Nutzerrolle
postgres
. Bei einer Neuinstallation hat diese Rolle Superuser-Berechtigungen und erfordert kein Passwort.Erstellen Sie neue Nutzerrollen mit der richtigen Zugriffsebene für die Tabellen Ihrer Anwendung. Verwenden Sie dazu wieder die Nutzerrolle
postgres
.Konfigurieren Sie Ihre Anwendung so, dass sie mit diesen neuen Rollen mit eingeschränktem Zugriff eine Verbindung zur Datenbank herstellt.
Sie können beliebig viele neue Nutzerrollen erstellen und definieren. Ändern oder löschen Sie keine der Nutzerrollen, die in AlloyDB Omni enthalten sind.
Weitere Informationen finden Sie unter AlloyDB-Nutzerrollen verwalten.
AlloyDB Omni überwachen
Wenn Sie Ihre AlloyDB Omni-Installation überwachen möchten, müssen Sie die zugehörigen Logdateien lesen und analysieren.
Für AlloyDB Omni, das auf Kubernetes ausgeführt wird, sind auch eine Reihe von grundlegenden Messwerten als Prometheus-Endpunkte verfügbar. Eine Liste der verfügbaren Messwerte finden Sie unter AlloyDB Omni-Messwerte.
Einzelserver
Führen Sie zum Abrufen von AlloyDB Omni-Logs standardmäßig Folgendes aus:
docker logs CONTAINER_NAME
Ersetzen Sie CONTAINER_NAME
durch den Namen Ihres AlloyDB Omni-Containers.
Informationen zum Konfigurieren des Logging-Verhaltens von AlloyDB Omni finden Sie unter AlloyDB Omni-Installation anpassen.
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:
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.Führen Sie eine Shell im Datenbank-Pod als Root aus.
kubectl exec ${DB_POD} -it -- /bin/bash
Die Logdateien finden Sie im Verzeichnis
/obs/diagnostic/
:/obs/diagnostic/postgresql.audit
/obs/diagnostic/postgresql.log
Monitoring-Dienste auflisten
v1.0
Wenn Sie einen Datenbankcluster erstellen, erstellt AlloyDB Omni den folgenden Überwachungsdienst für jede Instanz-CR des Datenbankclusters im selben Namespace:
al-INSTANCE_NAME-monitoring-system
Führen Sie den folgenden Befehl aus, um die Monitoring-Dienste 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
. Jeder Dienst entspricht einer 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 Monitoring-Dienste 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.
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
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
.
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 aktualisieren
Wenn Sie ein Upgrade von AlloyDB Omni 15.5.2 oder früher auf 15.5.4 durchführen möchten, folgen Sie der Anleitung unter Von einer früheren Version von AlloyDB Omni zur neuesten Version migrieren.
So führen Sie ein Upgrade von Version 15.5.4 und höher durch:
Starten Sie AlloyDB Omni mit einer neuen Image-Version neu.
Geben Sie das Datenverzeichnis so an, dass es mit dem Pfad übereinstimmt, der in früheren Versionen von AlloyDB Omni verwendet wurde.
AlloyDB Omni deinstallieren
Einzelserver
Wenn Sie AlloyDB Omni deinstallieren möchten, beenden und löschen Sie den AlloyDB Omni-Container mit dem folgenden Befehl:
docker container stop CONTAINER_NAME
docker container rm CONTAINER_NAME
Ersetzen Sie CONTAINER_NAME
durch den Namen Ihres AlloyDB Omni-Containers.
Sie können ein externes Datenverzeichnis verschieben, archivieren oder löschen, je nachdem, ob und wie Sie Ihre Daten nach der Deinstallation von AlloyDB Omni beibehalten 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:
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
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
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
Deinstallieren Sie den AlloyDB Omni Kubernetes-Operator:
helm uninstall alloydbomni-operator --namespace alloydb-omni-system
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
Größe des Kubernetes-basierten Datenbankclusters ändern
Wenn Sie die CPU, den Arbeitsspeicher oder den Speicher Ihres Kubernetes-basierten Datenbankclusters anpassen 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 Manifestsyntax des AlloyDB Omni-Operators finden Sie unter Datenbankcluster erstellen.
Für das Ändern der Ressourcen eines laufenden Datenbankclusters gelten die folgenden Einschränkungen:
- Sie können die Größe eines Laufwerks nur erhöhen, wenn das angegebene
storageClass
die Erweiterung von Volumes unterstützt. - Sie können die Größe eines Laufwerks nicht verringern.