Esegui l'upgrade di una versione secondaria del database per AlloyDB Omni su Kubernetes

Seleziona una versione della documentazione:

Questa pagina descrive come eseguire un upgrade della versione secondaria del database per AlloyDB Omni su Kubernetes.

Per eseguire l'upgrade di una versione secondaria del database, sono disponibili due opzioni:

  • Upgrade con tempi di inattività ridotti (LDTM): negli ambienti a disponibilità elevata (HA), l'operatore AlloyDB Omni esegue l'upgrade delle istanze di standby. Una volta eseguito l'upgrade di tutti gli standby, l'operatore esegue un failover, promuovendo una delle istanze di standby aggiornate a nuova istanza primaria. Una volta completato il cambio, viene eseguito l'upgrade della vecchia istanza primaria. Questo processo di implementazione sequenziale garantisce un downtime minimo e mantiene attivo il primario sulla versione precedente finché l'upgrade dell'ambiente di standby non viene completamente convalidato.
  • Upgrade simultaneo: negli ambienti non HA o se LDTM è disattivato in modo esplicito, l'operatore AlloyDB Omni esegue l'upgrade di tutte le istanze del database contemporaneamente. Questo metodo causa il downtime del database durante la procedura di upgrade.

Limitazioni

Durante il processo di upgrade con tempi di inattività ridotti, ogni istanza in standby viene aggiornata in sequenza e non è temporaneamente disponibile durante l'upgrade.

Per garantire che il cluster di database mantenga un Recovery Point Objective (RPO) pari a zero e non rischi la perdita di dati durante l'upgrade dello standby, è consigliabile disporre di almeno due istanze di standby. Questa configurazione funge da configurazione ad alta disponibilità a tre nodi.

Prima di iniziare

  • Se il tuo cluster è HA e la versione di AlloyDB Omni è precedente alla 15.7.1, segui i passaggi elencati in Aggiorna i cluster di database prima di seguire questa procedura di upgrade della versione secondaria.
  • Per evitare la perdita di dati, esegui il backup dei dati.
  • Mentre l'operazione di upgrade con tempi di inattività ridotti è in corso, la ridondanza HA del cluster di database viene temporaneamente ridotta mentre un'istanza in standby viene sottoposta all'upgrade. Tuttavia, il database rimane disponibile per il traffico di lettura e scrittura nell'istanza primaria attiva.

Abilita la procedura di upgrade della versione secondaria del database con tempi di inattività ridotti

Il processo di upgrade con tempi di inattività ridotti (LDTM) è attivato automaticamente per impostazione predefinita se il cluster di database ha due o più standby.

Se il cluster di database ha un solo standby, devi attivare manualmente LDTM aggiungendo l'annotazione dbcluster.dbadmin.goog/enableLDTM=true al cluster di database:

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME
dbcluster.dbadmin.goog/enableLDTM=true

Sostituisci la seguente variabile:

  • DB_CLUSTER_NAME: il nome del cluster di database. È lo stesso nome del cluster di database che hai fornito al momento della creazione. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.

Esegui l'upgrade della versione di AlloyDB Omni

Per eseguire l'upgrade alla versione 18.3.0, aggiorna i campi databaseVersion e controlPlaneAgentsVersion nel file manifest del cluster, quindi riapplica il file.

Di seguito è riportato l'inizio di un file manifest che specifica la versione 18.3.0 per databaseVersion e la versione 1.8.2 per controlPlaneAgentsVersion:

apiVersion: alloydbomni.dbadmin.goog/v1
kind: DBCluster
metadata:
    name: DB_CLUSTER_NAME
spec:
    databaseVersion: "DB_VERSION"
    controlPlaneAgentsVersion: "CONTROL_PLANE_AGENTS_VERSION"
    # It is recommended to switch to UBI9 for improved security and
    # compatibility.
    # If you need to stick to Debian, set this field to "Debian".
    databaseImageOSType: "OS_TYPE"
...

Sostituisci la seguente variabile:

  • DB_CLUSTER_NAME: il nome del cluster di database. È lo stesso nome del cluster di database che hai fornito al momento della creazione. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.
  • DB_VERSION: la versione del database a cui stai eseguendo l'upgrade.
  • CONTROL_PLANE_AGENTS_VERSION: la versione degli agenti del control plane.
  • OS_TYPE: (Facoltativo) Il sistema operativo di base per l'immagine del database. I valori validi sono Debian e UBI9. Se non lo specifichi, l'operatore lo imposta automaticamente su Debian se databaseVersion è inferiore a 16.9.0 e su UBI9 se databaseVersion è 16.9.0 o versioni successive.

Monitorare il processo di upgrade

Dopo aver aggiornato il file manifest, l'operatore AlloyDB Omni avvia la procedura di upgrade. Per monitorare il processo di upgrade, controlla la condizione DBCUpgradeInProgress.

kubectl get dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -o yaml | yq '.status.conditions[] | select(.type == "DBCUpgradeInProgress")'

Sostituisci la seguente variabile:

  • DB_CLUSTER_NAME: il nome del cluster di database. È lo stesso nome del cluster di database che hai fornito al momento della creazione. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.

Mentre il processo è in corso, lo stato della condizione è true. Al termine del processo, lo stato della condizione cambia in false e il motivo viene aggiornato a UpgradeComplete o UpgradeFailed.

Risoluzione dei problemi

Se ricevi messaggi di errore durante la procedura di upgrade, consulta le sezioni seguenti:

Errori pre-upgrade

Se ricevi un errore pre-upgrade sul cluster di database, controlla il messaggio e risolvi il problema di conseguenza.

Se vuoi ignorare il messaggio di errore pre-upgrade, puoi attivare l'annotazione force-upgrade.

kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/force-upgrade=true

Sostituisci la seguente variabile:

  • DB_CLUSTER_NAME: il nome del cluster di database. È lo stesso nome del cluster di database che hai fornito al momento della creazione. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.

Al termine della procedura di upgrade, imposta l'annotazione force-upgrade su false.

Errori di upgrade

Durante il processo di upgrade automatico, ci sono diversi punti in cui potrebbe non riuscire negli ambienti HA. Per saperne di più su ciascuno scenario di errore e sulle azioni successive intraprese dall'operatore AlloyDB Omni, consulta la tabella seguente.

Messaggio di errore Descrizione Azioni utente richieste
Standby instance upgrade succeeded but its replication lag is too high to be promoted to a synchronous standby. Please monitor replication status. L'istanza in standby è stata aggiornata correttamente, ma non è riuscita a raggiungere l'istanza primaria abbastanza velocemente da soddisfare la soglia di replica sincrona prima della finestra di timeout. Ciò è in genere causato da un traffico di scrittura elevato sull'istanza primaria.

Per consentire la sincronizzazione dell'istanza in standby, procedere come segue:

  1. Attendi che il traffico di scrittura diminuisca in modo che l'istanza in standby recuperi gradualmente. L'operatore AlloyDB Omni lo promuove automaticamente una volta sincronizzato.
  2. (Facoltativo) Puoi aumentare il timeout di recupero impostando l'annotazione upgrade.alloydbomni.dbadmin.google/standby-catch-up-timeout-in-minutes sul DBCluster.
All standbys upgrade succeeded but the switchover instance failed to promote an upgraded standby. L'upgrade delle istanze di standby è stato eseguito correttamente, ma il processo di failover automatico progettato per promuovere un'istanza di standby aggiornata a principale non è riuscito.

Per esaminare e risolvere l'errore di switchover, segui questi passaggi:

  1. Ispeziona lo stato della risorsa personalizzata di trasferimento per determinare la causa principale:
    kubectl get switchovers.alloydbomni.dbadmin.goog -n NAMESPACE
  2. Controlla i log e gli eventi del controller di trasferimento per rilevare problemi come partizioni di rete o latenza API.
  3. Scegli un'opzione in Correggi le istanze principali e di standby con versioni secondarie diverse.
Standby instance upgrade failed but rollback to the previous versions succeeded L'upgrade dell'istanza di standby non è riuscito, ma l'operatore AlloyDB Omni ha eseguito il rollback dell'istanza alla versione precedente funzionante. Poiché l'istanza principale non è mai stata toccata, il database rimane integro nella versione precedente.

Per diagnosticare il problema sottostante e applicare una correzione, segui questi passaggi:

  1. Esegui la diagnosi dell'errore di upgrade esaminando i log e gli eventi del pod di standby:
    kubectl describe pod -l alloydbomni.dbadmin.goog/instance=[standby-name] -n NAMESPACE
  2. Una volta risolto il problema, ad esempio l'esaurimento delle risorse dei nodi o i taint, scegli un'opzione in Correggi le istanze primaria e di standby con versioni secondarie diverse.
Standby instance upgrade failed and rollback to the previous versions failed L'upgrade dell'istanza in standby non è riuscito e anche il tentativo automatico dell'operatore AlloyDB Omni di eseguire il rollback alla versione precedente non è riuscito. L'istanza in standby viene lasciata in uno stato non integro/inutilizzabile (riducendo la ridondanza HA), mentre la primaria continua a gestire il traffico di lettura/scrittura nella versione precedente.

Per ripristinare l'integrità del cluster, esegui di nuovo il provisioning dello standby nel seguente modo:

  1. Elimina l'istanza in standby non integra impostando il conteggio delle istanze in standby su 0 nella specifica DBCluster:
    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE --type=merge -p '{"spec": {"availability": {"numberOfStandbys": 0}}}'
  2. Attendi l'eliminazione completa dell'istanza in standby danneggiata e del relativo pod.
  3. Aumenta di nuovo il conteggio di standby per eseguire il provisioning di un'istanza in standby pulita che verrà sincronizzata automaticamente con la primaria attiva:
    kubectl patch dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME -n NAMESPACE --type=merge -p '{"spec": {"availability": {"numberOfStandbys": 1}}}'

Correggere le istanze primaria e in standby con versioni secondarie diverse

Per risolvere il problema, scegli una delle seguenti opzioni:

  • Se il problema di base che ha causato l'errore di upgrade è stato risolto, puoi riavviare l'upgrade. Rimuovi l'annotazione start-time dell'upgrade da DBCluster per richiedere all'operatore AlloyDB Omni di generare un nuovo orario di inizio e riprovare:

    kubectl annotate dbclusters.alloydbomni.dbadmin.goog DB_CLUSTER_NAME upgrade.alloydbomni.dbadmin.google/start-time-

    Sostituisci DB_CLUSTER_NAME con il nome del cluster di database. È lo stesso nome del cluster di database che hai fornito al momento della creazione. Per saperne di più, consulta Installare AlloyDB Omni su Kubernetes.

  • Se il problema che ha causato l'errore di upgrade persiste e preferisci mantenere il cluster nella versione precedente, non devi eseguire una procedura di downgrade. Poiché l'upgrade non è riuscito durante la fase di standby, il database primario non è mai stato aggiornato.

    Per cancellare lo stato UpgradeFailed e tornare a uno stato stabile e non di upgrade, aggiorna i campi databaseVersion e controlPlaneAgentsVersion del manifest DBCluster alle versioni utilizzate prima del tentativo di upgrade, quindi riapplica il file.