Questa pagina documenta la versione 18.1.0 di AlloyDB Omni utilizzando l'opzione di deployment orchestratore di container. Scegli un'altra opzione di implementazione.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Esegui l'upgrade dell'operatore AlloyDB Omni Kubernetes alla versione 1.7.0

Seleziona una versione della documentazione:

Questa pagina descrive come eseguire l'upgrade dell'operatore AlloyDB Omni alla versione 1.7.0. I passaggi per l'upgrade dipendono dalla versione attuale di AlloyDB Omni e dalla versione a cui esegui l'upgrade.

Prima di iniziare

Quando esegui l'upgrade dell'operatore AlloyDB Omni, il database viene riavviato, a meno che non siano vere tutte le seguenti condizioni:

Stai eseguendo l'upgrade dell'operatore AlloyDB Omni dalla versione 1.1.1 a una versione più recente.
Stai utilizzando la versione del database AlloyDB Omni 15.5.5 o successive.
AlloyDB AI non è abilitato. Per saperne di più, consulta Creare un cluster di database con AlloyDB AI.

Se il database viene riavviato, non è prevista alcuna perdita di dati.

A partire dalla versione del database AlloyDB Omni 15.7.1, l'alta disponibilità (HA) nei cluster di database AlloyDB Omni basati su Kubernetes utilizza una nuova architettura per fornire maggiore protezione e miglioramenti per la configurazione automatica dell'alta disponibilità, il failover e le funzionalità di ripristino.

Se esegui l'upgrade della versione del database AlloyDB Omni dalla versione 15.7.0 (o precedenti) alla versione 15.7.1 (o successive) o se esegui il downgrade delle versioni, devi disabilitare l'alta disponibilità e riabilitarla al termine della procedura.

Determinare le versioni attuali

Per controllare la versione di AlloyDB Omni utilizzata dal cluster di database, esegui il seguente 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 l'hai creato. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.
NAMESPACE: lo spazio dei nomi Kubernetes del cluster di database.

Se esegui la versione 1.0.0 o successive dell'operatore AlloyDB Omni, questo comando stampa la versione di AlloyDB Omni utilizzata dal cluster di database.

Per controllare la versione dell'operatore AlloyDB Omni installata sul cluster Kubernetes, esegui il seguente 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, l'output è il numero di versione dell'operatore AlloyDB Omni in esecuzione sul cluster Kubernetes.

Se esegui una versione dell'operatore AlloyDB Omni precedente alla 1.0.0, segui le istruzioni riportate in Eseguire l'upgrade da un operatore AlloyDB Omni precedente alla versione 1.0.0. In caso contrario, controlla i numeri di versione di destinazione.

Controllare i numeri di versione di destinazione

Se esegui una versione dell'operatore AlloyDB Omni 1.0.0 o successive, i passaggi successivi dipendono dalla versione di AlloyDB Omni a cui vuoi eseguire l'upgrade. Il numero di versione di AlloyDB Omni ha i seguenti componenti:

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 18.1.0 di AlloyDB Omni supporta la versione 15.7 di PostgreSQL e non ha una patch di release di AlloyDB Omni.

Scegli l'opzione di installazione adatta alla versione di destinazione:

Scenario di installazione	Passaggi di aggiornamento
Vuoi eseguire l'upgrade a una versione di AlloyDB Omni che supporta una versione più recente di PostgreSQL.	Esegui l'upgrade dell'operatore AlloyDB Omni e del cluster di database. Ogni insieme di release di AlloyDB Omni che supporta una versione secondaria specifica di PostgreSQL ha il proprio numero di versione dell'operatore AlloyDB Omni. Utilizza la tabella di compatibilità delle versioni dell'operatore AlloyDB Omni per verificare che la versione dell'operatore AlloyDB Omni sia compatibile con la versione dell' operatore.
Vuoi eseguire l'upgrade solo a una versione della patch più recente di AlloyDB Omni.	Esegui l'upgrade solo del cluster di database.
Tutti gli altri scenari	Segui i passaggi descritti in Eseguire l'upgrade dell'operatore AlloyDB Omni.

Eseguire l'upgrade dell'operatore AlloyDB Omni

Per eseguire l'upgrade dell'operatore AlloyDB Omni:

Helm Kubernetes

Aggiorna le definizioni di risorse personalizzate (CRD) estraendo il grafico e applicandole manualmente:

helm pull oci://gcr.io/alloydb-omni/alloydbomni-operator --version 1.7.0 --untar
kubectl apply -f ./alloydbomni-operator/crds

Esegui l'upgrade del grafico Helm dell'operatore AlloyDB Omni:

helm upgrade alloydbomni-operator oci://gcr.io/alloydb-omni/alloydbomni-operator \
  --version 1.7.0 \
  --namespace alloydb-omni-system \
  --atomic \
  --timeout 5m

OLM OperatorHub.io

Al momento dell'installazione, utilizzi una strategia di approvazione dell'upgrade manuale o automatica. Se scegli una strategia di upgrade automatico, OLM esegue l'upgrade della versione dell'operatore alla versione più recente quando viene rilasciata. Se scegli una strategia di upgrade manuale, segui le istruzioni di OLM per approvare il piano di installazione quando diventa disponibile una nuova release. Per saperne di più, consulta Approvare manualmente gli upgrade tramite gli abbonamenti.

OLM Red Hat OpenShift

Puoi approvare l'upgrade dell'operatore utilizzando la console web di OpenShift per la versione di OpenShift che stai utilizzando.

Aggiornare i cluster di database OpenShift dalla versione 1.4.1 o precedenti

A partire dalla versione 1.5.0, l'operatore AlloyDB Omni è compatibile con il vincolo del contesto di sicurezza restricted-v2 predefinito di OpenShift. Per i nuovi cluster di database su OpenShift che eseguono controlPlaneAgentsVersion 1.5.0 o versioni successive, OpenShift inserisce ID utente arbitrari per i carichi di lavoro del database. Per i cluster di database che eseguono una versione precedente, i carichi di lavoro del database devono continuare a essere eseguiti come ID utente predefinito 999.

Per aggiornare un cluster di database su OpenShift da una controlPlaneAgentsVersion precedente alla 1.5.0:

Concedi al account di servizio del cluster di database l'autorizzazione a utilizzare il vincolo del contesto di sicurezza anyuid. In questo modo, il carico di lavoro del database può essere eseguito come ID utente predefinito.
```
oc adm policy add-scc-to-user anyuid system:serviceaccount:NAMESPACE:DB_CLUSTER_NAME-sa
```
Aggiungi l'annotazione openshift.io/scc=anyuid al cluster di database. L'operatore AlloyDB Omni versione 1.5.0 o successive riconosce questa annotazione ed esegue i carichi di lavoro del database come ID utente predefinito su OpenShift anziché consentire alla piattaforma di inserire un ID arbitrario.
```
kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE openshift.io/scc=anyuid
```
Procedi con i passaggi per aggiornare il cluster di database all'ultima versione.

Aggiornare i cluster di database

Per aggiornare dbCluster:

Se esegui l'upgrade di un cluster di database AlloyDB Omni ad alta disponibilità dalla versione del database 15.7.0 (o precedenti) alla versione 15.7.1 (o successive), segui questi passaggi per disabilitare l'alta disponibilità.

Nota: se esegui l'upgrade da una versione precedente alla versione 15.7.0 (o precedenti) o dalla versione 15.7.1 (o successive) a una versione più recente, salta questo passaggio.
1. Imposta numberOfStandbys su 0 nel manifest del cluster.
```
spec:
  availability:
    numberOfStandbys: 0
```
1. Per disabilitare l'alta disponibilità, riapplica il manifest.
Aggiorna le versioni databaseVersion e controlPlaneAgentsVersion nel manifest del cluster e riapplica il manifest.

Esegui il seguente esempio, che fa parte di un file manifest che specifica la versione 18.1.0 di databaseVersion e la versione 1.7.0 di controlPlaneAgentsVersion:
```
apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
  name: DB_CLUSTER_NAME
  namespace: NAMESPACE
spec:
  databaseVersion: "18.1.0"
  controlPlaneAgentsVersion: "1.7.0"
...
```
Sostituisci la seguente variabile:
- DB_CLUSTER_NAME: il nome del cluster di database. È lo stesso nome del cluster di database che hai dichiarato quando l'hai creato. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.
- NAMESPACE: lo spazio dei nomi Kubernetes del cluster di database.
Attendi il completamento dell'upgrade.
Se hai disabilitato l'alta disponibilità prima dell'upgrade, completa i seguenti passaggi.
1. Imposta di nuovo numberOfStandbys sul numero precedente all'upgrade nel manifest del cluster.
2. Riapplica il manifest per riabilitare l'alta disponibilità.

Aggiornare `alloydb_omni_instance_postgresql_wait_time_second_total`

Se utilizzi la metrica alloydb_omni_instance_postgresql_wait_time_second_total, devi aggiornarla a alloydb_omni_instance_postgresql_wait_time_us_total. Per utilizzare entrambe le metriche, usa l'operatore OR di Prometheus.

(promQL A) OR (promQL A, but replace all occurrences of alloydb_omni_instance_postgresql_wait_time_second_total to alloydb_omni_instance_postgresql_wait_time_us_total)

Se utilizzi seconds come unità per questa metrica, devi convertirla in us.

Per saperne di più, consulta le note di rilascio.