Gestire e monitorare AlloyDB Omni

Questa pagina descrive come gestire i ruoli utente di AlloyDB Omni, monitorare l'attività del server AlloyDB Omni e aggiornare o rimuovere l'installazione di AlloyDB Omni.

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 superutente denominato alloydbadmin.

Come per AlloyDB, è buona norma seguire questi passaggi durante la configurazione di un database:

  1. Definisci o importa i database utilizzando il ruolo utente postgres. In una nuova installazione, questo ruolo ha privilegi di creazione di database e ruoli e non ha password.

  2. Crea nuovi ruoli utente con il livello di accesso corretto alle tabelle della tua applicazione, utilizzando di nuovo il ruolo utente postgres.

  3. Configura l'applicazione in modo che si connetta al database utilizzando questi nuovi ruoli con accesso limitato.

Puoi creare e definire tutti i nuovi ruoli utente di cui hai bisogno. Non modificare o eliminare i ruoli utente forniti con AlloyDB Omni.

Per saperne di più, consulta Gestire i ruoli degli utenti AlloyDB.

Monitora AlloyDB Omni

Il monitoraggio dell'installazione di AlloyDB Omni consiste nel leggere e analizzare i 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.

Single-server

AlloyDB Omni registra la propria attività in due luoghi:

  • AlloyDB Omni registra l'attività del database in data/log/postgres, in base alla directory che hai definito nel file di configurazione dataplane.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 le attività di installazione, avvio e spegnimento 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:

  1. 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 tuo cluster di database. Si tratta dello stesso nome del cluster di database dichiarato quando lo hai creato.

  2. Esegui un shell sul pod del database come utente root.

    kubectl exec ${DB_POD} -it -- /bin/bash
  3. 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 istanza CR del cluster di database nello stesso spazio dei nomi:

al-INSTANCE_NAME-monitoring-system

Per elencare i servizi di monitoraggio, esegui il seguente comando.

kubectl get svc -n NAMESPACE | grep monitoring

Sostituisci NAMESPACE con uno spazio dei nomi a cui appartiene il tuo 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 il seguente comando.

kubectl get svc -n NAMESPACE | grep monitoring

Sostituisci NAMESPACE con uno spazio dei nomi a cui appartiene il tuo cluster.

L'esempio di risposta seguente mostra il servizio al-2953-dbcluster-foo7-monitoring-system e 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.

  1. Configura l'inoltro delle porte dal tuo 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 esempio al-1060-dbc-monitoring-system.

    • NAMESPACE: lo spazio dei nomi a cui appartiene il cluster.

    • MONITORING_METRICS_PORT: una porta TCP disponibile localmente.

    La seguente risposta mostra che i servizi vengono inoltrati.

    Forwarding from 127.0.0.1:9187 -> 9187
    Forwarding from [::1]:9187 -> 9187
    
  2. Durante l'esecuzione del comando precedente, puoi accedere alle metriche di monitoraggio tramite HTTP sulla porta specificata. Ad esempio, puoi utilizzare curl per visualizzare tutte le metriche in 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 ulteriori informazioni 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

Eseguire l'upgrade di AlloyDB Omni

Single-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 successiva dell'interfaccia a riga di comando AlloyDB Omni.

Esegui l'upgrade

Per eseguire l'upgrade dell'installazione di AlloyDB Omni, esegui il seguente comando:

sudo alloydb database-server upgrade

Kubernetes

I passaggi 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.

Determina 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. Si tratta dello stesso nome del cluster di database dichiarato quando lo hai creato.

  • NAMESPACE: lo spazio dei nomi Kubernetes del cluster di database.

Se utilizzi la versione 1.0.0 o successiva 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 utilizzi 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 tuo cluster Kubernetes.

Se utilizzi una versione di AlloyDB Omni Operator precedente alla 1.0.0, non puoi eseguire un upgrade in situ del cluster di database o dell'operatore AlloyDB Omni. Devi invece seguire le istruzioni riportate in Eseguire l'upgrade da un operatore AlloyDB Omni precedente alla versione 1.0.0.

In caso contrario, vai alla sezione successiva.

Determina i numeri di versione target

Se esegui una versione di AlloyDB Omni Operator 1.0.0 o successiva, i passaggi successivi dipendono dalla versione di AlloyDB Omni a cui vuoi eseguire l'upgrade. Questo, a sua volta, richiede la conoscenza del numero di versione di AlloyDB Omni.

Il numero di versione di AlloyDB Omni è composto da tre parti:

  • Il numero della versione principale della compatibilità con PostgreSQL
  • Il numero della 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 versione della 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 stesso insieme al tuo cluster di database. Ogni insieme di release di AlloyDB Omni che supporta una determinata versione minore di PostgreSQL ha il proprio numero di versione dell'operatore AlloyDB Omni associato, che puoi trovare nella release note della 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 andare alle istruzioni in Eseguire l'upgrade del cluster di database.

In caso contrario, vai alla sezione successiva.

Eseguire l'upgrade dell'operatore AlloyDB Omni

Per eseguire l'upgrade dell'operatore AlloyDB Omni:

  1. 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 esempio 1.1.0.

  2. Scarica l'operatore AlloyDB Omni più recente:

    gcloud storage cp gs://$GCS_BUCKET/$HELM_PATH ./ --recursive
    tar -xvzf alloydbomni-operator-${OPERATOR_VERSION}.tgz
  3. Applica le definizioni delle risorse personalizzate dell'operatore AlloyDB Omni più recenti:

    kubectl apply -f alloydbomni-operator/crds
  4. 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 l'upgrade dell'operatore AlloyDB Omni aggiornando sia il manifest Kubernetes sia il cluster di database, segui le istruzioni riportate nella sezione successiva subito dopo aver completato i passaggi precedenti.

Esegui l'upgrade del cluster di database

Per eseguire l'upgrade del cluster di database, aggiorna i seguenti campi nella sezione spec del file 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 dell'operatore AlloyDB Omni di cui hai eseguito l'upgrade.

Se stai eseguendo l'upgrade solo della versione con patch di AlloyDB Omni, ad esempio aggiornando databaseVersion da 15.5.1 a 15.5.2, questo passaggio è tutto ciò che devi fare.

Se esegui l'upgrade della versione minore della compatibilità con PostgreSQL, ad esempio aggiornando databaseVersion da 15.4.1 a 15.5.2, devi aggiornare anche controlPlaneAgentsVersion. In questo caso, assicurati di aver seguito i passaggi aggiuntivi descritti in Eseguire l'upgrade dell'operatore AlloyDB Omni.

Ad esempio, il seguente estratto del manifest definisce un cluster di database che esegue AlloyDB Omni Operator versione 15.5.2 con AlloyDB Omni Operator versione 1.0.0:

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 in modo da eseguire AlloyDB Omni versione 15.5.3, cambia databaseVersion: 15.5.2 in databaseVersion: 15.5.3.

Eseguire l'upgrade da un operatore AlloyDB Omni precedente alla versione 1.0.0

Se utilizzi una versione di AlloyDB Omni Operator precedente alla 1.0.0, l'upgrade di un'installazione di AlloyDB Omni basata su Kubernetes prevede la disinstallazione e la reinstallazione di AlloyDB Omni Operator dopo il backup dei dati. Segui questi passaggi:

  1. Elenca tutti i cluster di database:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  2. Per ogni cluster di database, utilizza il comando pg_dumpall per esportarne tutti i dati.

  3. Disinstalla l'operatore AlloyDB Omni. Ciò include l'eliminazione di tutti i cluster di database.

  4. Reinstalla l'operatore AlloyDB Omni. Puoi utilizzare gli stessi comandi utilizzati per installare la versione precedente dell'operatore AlloyDB Omni, senza dover specificare un nuovo numero di versione.

  5. Rigenera i cluster di database. Puoi adattare gli stessi file manifest che hai utilizzato per creare i cluster di database in precedenza. Potresti dover aggiornare i file in modo che riflettano le modifiche all'API introdotte dalla versione 1.0.0 dell'operatore Omni di AlloyDB, ad esempio l'attributo databaseVersion che sostituisce l'attributo version precedente.

  6. Utilizza pg_restore o il comando \i in psql per importare i dati esportati in precedenza nei cluster ricreati.

Esegui il rollback di un upgrade

Queste istruzioni si applicano solo ad AlloyDB Omni dalla versione 15.2.1 alla 15.5.2. Non si applicano ai deployment di AlloyDB Omni basati su Kubernetes.

Per eseguire il rollback di AlloyDB Omni alla versione installata in precedenza, esegui questo comando:

sudo alloydb database-server rollback

Disinstalla AlloyDB Omni

Single-server

Per disinstallare AlloyDB Omni, esegui il seguente 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 conservare i dati e in che modo dopo aver disinstallato AlloyDB Omni.

Kubernetes

Eliminare il cluster di database

Per eliminare il cluster di database, imposta isDeleted su true nel relativo file 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 tuo cluster di database. Si tratta dello stesso nome del cluster di database dichiarato quando lo hai creato.

Disinstalla l'operatore AlloyDB Omni

Per disinstallare l'operatore AlloyDB Omni Kubernetes dal tuo cluster Kubernetes, segui questi passaggi:

  1. 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
  2. Attendi che l'operatore Kubernetes AlloyDB Omni elimini tutti i cluster di database. Utilizza il seguente comando per verificare se sono presenti risorse di database:

    kubectl get dbclusters.alloydbomni.dbadmin.goog --all-namespaces
  3. 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
  4. Disinstalla l'operatore AlloyDB Omni Kubernetes:

    helm uninstall alloydbomni-operator --namespace alloydb-omni-system
  5. Ripulisci i secret, le descrizioni delle risorse personalizzate e gli spazi dei nomi relativi 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.

Le seguenti limitazioni si applicano 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.