Gestire i ruoli utente
AlloyDB Omni utilizza lo stesso insieme di ruoli utente PostgreSQL predefiniti inclusi in AlloyDB, con le seguenti differenze:
AlloyDB Omni non ha un ruolo
alloydbiamuser
.AlloyDB Omni include un ruolo di superuser denominato
alloydbadmin
.
Come per AlloyDB, è una best practice seguire questi passaggi quando configuri un database:
Definisci o importa i tuoi database utilizzando il ruolo utente
postgres
. In una nuova installazione, questo ruolo dispone dei privilegi di creazione di database e ruoli e non ha password.Crea nuovi ruoli utente con il livello di accesso corretto alle tabelle della tua applicazione, utilizzando di nuovo il ruolo utente
postgres
.Configura l'applicazione per connettersi al database utilizzando questi nuovi ruoli con accesso limitato.
Puoi creare e definire tutti i nuovi ruoli utente che ti servono. Non modificare o eliminare nessuno dei ruoli utente forniti con AlloyDB Omni.
Per saperne di più, consulta Gestire i ruoli utente di AlloyDB.
Monitora AlloyDB Omni
Il monitoraggio dell'installazione di AlloyDB Omni comporta la lettura e l'analisi dei file di log.
AlloyDB Omni in esecuzione su Kubernetes dispone anche di un insieme di metriche di base disponibili come endpoint Prometheus. Per un elenco delle metriche disponibili, consulta Metriche di AlloyDB Omni.
A un solo server
AlloyDB Omni registra la sua attività in due posizioni:
AlloyDB Omni registra l'attività del database in
data/log/postgres
, rispetto alla directory definita nel file di configurazionedataplane.conf
.Puoi personalizzare il nome e il formato di questo file di log tramite le varie direttive
log_*
definite in/var/alloydb/config/postgresql.conf
. Per maggiori informazioni, consulta Error Reporting e Logging.AlloyDB Omni registra l'installazione, l'avvio e l'arresto dell'attività in
/var/alloydb/logs/alloydb.log
.
Per controllare lo stato di esecuzione immediato del server, consulta Controllare lo stato di AlloyDB Omni.
Kubernetes
Trovare i file di log del cluster di database
Puoi trovare i file postgresql.audit
e postgresql.log
nel file system
del pod del database. Per accedere a questi file:
Definisci una variabile di ambiente contenente il nome del pod del database.
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}'`
Sostituisci
DB_CLUSTER_NAME
con il nome del cluster di database. È lo stesso nome del cluster di database che hai dichiarato quando lo hai creato.Esegui una shell sul pod del database come root.
kubectl exec ${DB_POD} -it -- /bin/bash
Trova i file di log nella directory
/obs/diagnostic/
:/obs/diagnostic/postgresql.audit
/obs/diagnostic/postgresql.log
Elenco dei servizi di monitoraggio
v1.0
Quando crei un cluster di database, AlloyDB Omni crea il seguente servizio di monitoraggio per ogni CR dell'istanza del cluster di database nello stesso spazio dei nomi:
al-INSTANCE_NAME-monitoring-system
Per elencare i servizi di monitoraggio, esegui questo comando.
kubectl get svc -n NAMESPACE | grep monitoring
Sostituisci NAMESPACE
con uno spazio dei nomi a cui appartiene il cluster.
La seguente risposta di esempio mostra i servizi al-1060-dbc-monitoring-system
,
al-3de6-dbc-monitoring-system
e al-4bc0-dbc-monitoring-system
. Ogni servizio corrisponde a un'istanza.
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
Versione < 1.0
Quando crei un cluster di database, AlloyDB Omni crea i seguenti servizi di monitoraggio nello stesso spazio dei nomi del cluster di database:
DB_CLUSTER-monitoring-db
DB_CLUSTER-monitoring-system
Per elencare i servizi di monitoraggio, esegui questo comando.
kubectl get svc -n NAMESPACE | grep monitoring
Sostituisci NAMESPACE
con uno spazio dei nomi a cui appartiene il cluster.
La seguente risposta di esempio mostra al-2953-dbcluster-foo7-monitoring-system
e il servizio al-2953-dbcluster-foo7-monitoring-db
.
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
Visualizzare le metriche Prometheus dalla riga di comando
La porta 9187
è denominata metricsalloydbomni
per tutti i servizi di monitoraggio.
Configura il port forwarding dall'ambiente locale al servizio di monitoraggio.
kubectl port-forward service/MONITORING_SERVICE -n NAMESPACE MONITORING_METRICS_PORT:metricsalloydbomni
Sostituisci quanto segue:
MONITORING_SERVICE
: il nome del servizio di monitoraggio che vuoi inoltrare, ad esempioal-1060-dbc-monitoring-system
.NAMESPACE
: lo spazio dei nomi a cui appartiene il cluster.MONITORING_METRICS_PORT
: una porta TCP locale disponibile.
La seguente risposta mostra che i servizi vengono inoltrati.
Forwarding from 127.0.0.1:9187 -> 9187 Forwarding from [::1]:9187 -> 9187
Mentre viene eseguito il comando precedente, puoi accedere alle metriche di monitoraggio tramite HTTP sulla porta che hai specificato. Ad esempio, puoi utilizzare
curl
per visualizzare tutte le metriche come testo normale:curl http://localhost:MONITORING_METRICS_PORT/metrics
Visualizzare le metriche utilizzando l'API Prometheus
La chiave dell'etichetta alloydbomni.internal.dbadmin.goog/task-type
e la porta metricsalloydbomni
sono disponibili per impostazione predefinita per tutti i servizi di monitoraggio in AlloyDB Omni. Puoi utilizzarli insieme a una singola risorsa personalizzata ServiceMonitor
per selezionare tutti i servizi per tutti gli spazi dei nomi nel cluster di database.
Per saperne di più sull'utilizzo dell'API Prometheus, consulta la documentazione di Prometheus Operator.
Di seguito è riportato un esempio di campo spec
della risorsa personalizzata ServiceMonitor
che include la chiave dell'etichetta alloydbomni.internal.dbadmin.gdc.goog/task-type
e la porta metricsalloydbomni
. La risorsa personalizzata ServiceMonitor
monitora e raccoglie tutti i servizi Kubernetes in tutti gli spazi dei nomi
Per ulteriori informazioni sulla definizione completa di ServiceMonitor
, consulta la definizione della risorsa personalizzata ServiceMonitor
.
v1.0
spec:
selector:
matchLabels:
alloydbomni.internal.dbadmin.goog/task-type: monitoring
namespaceSelector:
any: true
endpoints:
- port: metricsalloydbomni
Versione < 1.0
spec:
selector:
matchExpressions:
- key: alloydbomni.internal.dbadmin.gdc.goog/task-type
operator: Exists
values: []
namespaceSelector:
any: true
endpoints:
- port: metricsalloydbomni
Esegui l'upgrade di AlloyDB Omni
A un solo server
Queste istruzioni si applicano solo ad AlloyDB Omni versione 15.2.0 e successive.
Prima di iniziare
Sulla tua macchina deve essere installata la versione 1.2 o successive dell'interfaccia a riga di comando AlloyDB Omni.
Esegui l'upgrade
Per eseguire l'upgrade dell'installazione di AlloyDB Omni, esegui questo comando:
sudo alloydb database-server upgrade
Kubernetes
I passaggi da seguire per eseguire l'upgrade di AlloyDB Omni in Kubernetes dipendono dalla versione di AlloyDB Omni in esecuzione e dalla versione a cui esegui l'upgrade.
Determinare i numeri di versione correnti
Per controllare la versione di AlloyDB Omni utilizzata dal cluster di database, esegui questo comando:
kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentDatabaseVersion}'
Sostituisci quanto segue:
DB_CLUSTER_NAME
: il nome del cluster di database. È lo stesso nome del cluster di database che hai dichiarato quando lo hai creato.NAMESPACE
: lo spazio dei nomi Kubernetes del tuo cluster di database.
Se esegui la versione 1.0.0 o successive dell'operatore AlloyDB Omni, questo comando stampa la versione di AlloyDB Omni in uso dal tuo cluster di database.
Per controllare la versione dell'operatore AlloyDB Omni installato sul tuo cluster Kubernetes, esegui questo comando:
kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE -o jsonpath='{.status.primary.currentControlPlaneAgentsVersion}'
Se esegui la versione 1.0.0 o successive dell'operatore AlloyDB Omni, questo comando stampa il numero di versione dell'operatore AlloyDB Omni in esecuzione sul cluster Kubernetes.
Se esegui una versione di AlloyDB Omni Operator precedente alla 1.0.0, non puoi eseguire un upgrade in loco del cluster di database o di AlloyDB Omni Operator. Devi invece seguire le istruzioni riportate in Eseguire l'upgrade da una versione precedente alla 1.0.0 dell'operatore AlloyDB Omni.
In caso contrario, vai alla sezione successiva.
Determinare i numeri di versione di destinazione
Se esegui una versione di AlloyDB Omni Operator 1.0.0 o successive, i passaggi successivi dipendono dalla versione di AlloyDB Omni a cui vuoi eseguire l'upgrade. Ciò, a sua volta, richiede la comprensione del numero di versione di AlloyDB Omni.
Il numero di versione di AlloyDB Omni è composto da tre parti:
- Il numero di versione principale della compatibilità con PostgreSQL
- Il numero di versione secondaria della compatibilità con PostgreSQL
- Il numero di versione della patch di questa release di AlloyDB Omni
Ad esempio, la versione 15.5.2 di AlloyDB Omni è la patch 2 di AlloyDB Omni che supporta la versione 15.5 di PostgreSQL.
Se vuoi eseguire l'upgrade a una versione di AlloyDB Omni che supporta una versione più recente di PostgreSQL, devi eseguire l'upgrade dell'operatore AlloyDB Omni insieme al cluster di database. Ogni insieme di release di AlloyDB Omni che supportano una particolare versione secondaria di PostgreSQL ha il proprio numero di versione dell'operatore AlloyDB Omni associato, che puoi trovare nelle note di rilascio per la versione di AlloyDB Omni.
Se vuoi eseguire l'upgrade solo a una versione patch più recente di AlloyDB Omni, puoi eseguire l'upgrade solo del cluster di database, senza dover eseguire l'upgrade dell'operatore AlloyDB Omni stesso. Puoi passare direttamente alle istruzioni in Esegui l'upgrade del cluster di database.
In caso contrario, vai alla sezione successiva.
Esegui l'upgrade dell'operatore AlloyDB Omni
Per eseguire l'upgrade dell'operatore AlloyDB Omni:
Definisci le variabili di ambiente necessarie:
export GCS_BUCKET=alloydb-omni-operator
export OPERATOR_VERSION=OPERATOR_VERSION
export HELM_PATH=$OPERATOR_VERSION/alloydbomni-operator-$OPERATOR_VERSION.tgz
Sostituisci
OPERATOR_VERSION
con la versione dell'operatore AlloyDB Omni a cui stai eseguendo l'upgrade, ad esempio1.1.0
.Scarica l'operatore AlloyDB Omni più recente:
gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz
Applica le definizioni delle risorse personalizzate dell'operatore AlloyDB Omni più recenti:
kubectl apply -f alloydbomni-operator/crds
Esegui l'upgrade del grafico Helm dell'operatore AlloyDB Omni:
helm upgrade alloydbomni-operator alloydbomni-operator-${OPERATOR_VERSION}.tgz \ --namespace alloydb-omni-system \ --atomic \ --timeout 5m
Per eseguire il follow-up dell'upgrade dell'operatore AlloyDB Omni eseguendo l'upgrade sia del manifest Kubernetes sia del cluster di database, segui le istruzioni nella sezione successiva immediatamente dopo aver completato i passaggi precedenti.
Eseguire l'upgrade del cluster di database
Per eseguire l'upgrade del cluster di database, aggiorna i seguenti campi nella sezione spec
del manifest
che lo definisce:
Imposta
databaseVersion
sul numero di versione completo di AlloyDB Omni a cui vuoi eseguire l'upgrade di questo cluster di database.Se hai eseguito l'upgrade anche di AlloyDB Omni Operator, imposta
controlPlaneAgentsVersion
sul numero di versione completo di AlloyDB Omni Operator di cui hai eseguito l'upgrade.
Se esegui l'upgrade solo della versione patch di AlloyDB Omni, ad esempio l'aggiornamento di databaseVersion
da 15.5.1
a 15.5.2
, questo passaggio è tutto ciò che devi fare.
Se esegui l'upgrade della versione secondaria della compatibilità PostgreSQL, ad esempio l'aggiornamento di databaseVersion
da 15.4.1
a 15.5.2
, devi anche aggiornare controlPlaneAgentsVersion
. In questo caso, assicurati di aver seguito
i passaggi aggiuntivi elencati in Eseguire l'upgrade dell'operatore AlloyDB Omni.
Ad esempio, il seguente estratto del manifest definisce un cluster di database
che esegue la versione 15.5.2
di AlloyDB Omni Operator, con la versione 1.0.0
di AlloyDB Omni Operator:
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
name: dbcluster-sample
spec:
databaseVersion: 15.5.2
controlPlaneAgentsVersion: 1.0.0
In questo esempio, per eseguire l'upgrade del cluster di database per eseguire la versione di AlloyDB Omni
15.5.3
, modifica databaseVersion: 15.5.2
in databaseVersion: 15.5.3
.
Eseguire l'upgrade da una versione precedente alla 1.0.0 dell'operatore AlloyDB Omni
Se esegui una versione di AlloyDB Omni Operator precedente alla 1.0.0, l'upgrade di un'installazione di AlloyDB Omni basata su Kubernetes comporta la disinstallazione e la reinstallazione di AlloyDB Omni Operator dopo il backup dei dati. Segui questi passaggi:
Elenca tutti i cluster di database:
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
Per ogni cluster di database, utilizza il comando
pg_dumpall
per esportare tutti i relativi dati.Disinstalla l'operatore AlloyDB Omni. Ciò include l'eliminazione di tutti i cluster di database.
Reinstalla l'operatore AlloyDB Omni. Puoi utilizzare gli stessi comandi che hai utilizzato per installare la versione precedente dell'operatore AlloyDB Omni, senza dover specificare un nuovo numero di versione.
Ricrea i cluster di database. Puoi adattare gli stessi file manifest utilizzati in precedenza per creare i cluster di database. Potresti dover aggiornare i file per riflettere le modifiche all'API introdotte dalla versione 1.0.0 di AlloyDB Omni Operator, ad esempio l'attributo
databaseVersion
che sostituisce il precedente attributoversion
.Utilizza
pg_restore
o il comando\i
inpsql
per importare i dati esportati in precedenza nei cluster ricreati.
Esegui il rollback di un upgrade
Queste istruzioni si applicano solo alla versione di AlloyDB Omni da 15.2.1 a 15.5.2. Non si applicano ai deployment basati su Kubernetes di AlloyDB Omni.
Per eseguire il rollback di AlloyDB Omni alla versione installata in precedenza, esegui questo comando:
sudo alloydb database-server rollback
Disinstalla AlloyDB Omni
A un solo server
Per disinstallare AlloyDB Omni, esegui questo comando:
sudo alloydb database-server uninstall
La directory dei dati rimane nel file system dopo la disinstallazione di AlloyDB Omni. Puoi spostare, archiviare o eliminare questa directory, a seconda che tu voglia o meno conservare i dati dopo aver disinstallato AlloyDB Omni.
Kubernetes
Elimina il cluster di database
Per eliminare il cluster di database, imposta isDeleted
su true
nel relativo manifest.
Puoi farlo con il seguente comando.
kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -p '{"spec":{"isDeleted":true}}' --type=merge
Sostituisci DB_CLUSTER_NAME
con il nome del cluster di database. È lo stesso nome del cluster di database che hai dichiarato quando lo hai
creato.
Disinstalla l'operatore AlloyDB Omni
Per disinstallare l'operatore AlloyDB Omni Kubernetes dal cluster Kubernetes, segui questi passaggi:
Elimina tutti i cluster di database:
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
Attendi che l'operatore AlloyDB Omni Kubernetes elimini tutti i cluster di database. Utilizza il seguente comando per verificare se sono rimaste risorse di database:
kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
Elimina le altre risorse create dall'operatore AlloyDB Omni Kubernetes:
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
Disinstalla l'operatore AlloyDB Omni Kubernetes:
helm uninstall alloydbomni-operator --namespace alloydb-omni-system
Pulisci i secret, le descrizioni delle risorse personalizzate e gli spazi dei nomi correlati all'operatore AlloyDB Omni Kubernetes:
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
Ridimensiona il cluster di database basato su Kubernetes
Per ridimensionare la CPU, la memoria o lo spazio di archiviazione del cluster di database basato su Kubernetes,
aggiorna il campo resources
dei manifest che definiscono il relativo pod. L'operatore AlloyDB Omni applica immediatamente le nuove specifiche al pod del database.
Per ulteriori informazioni sulla sintassi del manifest dell'operatore AlloyDB Omni, consulta Creare un cluster di database.
Si applicano le seguenti limitazioni alla modifica delle risorse di un cluster di database in esecuzione:
- Puoi aumentare le dimensioni di un disco solo se il
storageClass
specificato supporta l'espansione del volume. - Non puoi ridurre le dimensioni di un disco.