Panoramica dell'upgrade della versione principale in loco del database

Questo documento descrive gli upgrade in place delle versioni principali del database AlloyDB per PostgreSQL, che consentono di eseguire l'upgrade di un database a una versione più recente senza eseguire la migrazione dei dati o sostituire l'istanza esistente.

La community PostgreSQL rilascia periodicamente nuove versioni principali che contengono nuove funzionalità, miglioramenti delle prestazioni e della sicurezza. Dopo che PostgreSQL rilascia una nuova versione principale, AlloyDB aggiunge il supporto per la versione compatibile. Per mantenere aggiornato il database, puoi eseguire l'upgrade del cluster AlloyDB a una versione principale successiva. Puoi eseguire l'upgrade del cluster utilizzando questa funzionalità di upgrade in situ o eseguendo la migrazione dei dati in un nuovo cluster AlloyDB.

Per ulteriori informazioni, consulta Norme relative alle versioni dei database.

Gli upgrade in-place delle versioni principali sono un modo efficiente per eseguire l'upgrade della versione principale del cluster per i seguenti motivi:

  • AlloyDB conserva i dettagli del cluster e dell'istanza e le impostazioni del database come il nome dell'istanza, l'indirizzo IP e i flag del database dopo l'upgrade.
  • Non è necessario modificare le stringhe di connessione dell'applicazione.
  • L'upgrade di tutte le istanze del cluster (principale e pool di lettura) viene eseguito nell'ambito della stessa operazione.

Flusso di lavoro di upgrade in loco della versione principale

Quando avvii un upgrade sul cluster, AlloyDB esegue le seguenti azioni:

  1. Esegue controlli pre-upgrade per trovare incompatibilità che possono influire sull'upgrade.
  2. Prepara l'upgrade della versione principale, che include la creazione di un clone interno del cluster.
  3. Rende l'istanza principale non disponibile. Inizia il tempo di riposo. Le letture possono essere eseguite tramite i pool di lettura.
  4. Avvia un backup precedente all'upgrade.
  5. Esegue l'upgrade dell'istanza principale.
  6. Le istanze del pool di lettura non sono disponibili.
  7. Rende disponibile l'istanza principale. Il tempo di riposo termina.
  8. Avvia un backup post-upgrade.
  9. Esegue l'upgrade delle istanze del pool di lettura.

Una volta superati i controlli di pre-upgrade, il cluster viene clonato in un cluster interno nello stesso progetto. Il backup e il ripristino necessari per clonare il cluster potrebbero richiedere un po' di tempo, a seconda delle dimensioni del database. Di seguito sono riportati alcuni esempi di dimensioni del database e delle relative durate di backup e ripristino:

  • La clonazione di un cluster da 1 TB richiede circa 30 minuti.
  • Per clonare un cluster da 10 TB sono necessarie circa 2 ore.

Durante l'operazione di clonazione, puoi continuare a utilizzare il cluster originale. Al termine dell'operazione di clonazione, inizia il processo di upgrade. L'istanza principale non è disponibile sia per le letture sia per le scritture finché non viene eseguito l'upgrade dell'istanza principale. Il tempo di riposo previsto è in genere compreso tra 20 minuti e un'ora e dipende principalmente dallo schema del database e dal numero di oggetti.

Se l'upgrade alla versione principale non riesce in un qualsiasi passaggio prima dell'upgrade dell'istanza principale, AlloyDB esegue automaticamente il rollback di tutte le modifiche.

Dopo l'upgrade dell'istanza principale, viene eseguito l'upgrade della versione del cluster alla versione di destinazione e non vengono attivati rollback per eventuali errori dopo questo punto. Ad esempio, AlloyDB non esegue il rollback del cluster se uno o più upgrade delle istanze del pool di lettura non riescono. In queste situazioni, contatta l'assistenza per Google Cloud CLI.

Per ulteriori informazioni, vedi Eseguire l'upgrade in situ di una versione principale del database.

Stato upgrade

Puoi monitorare lo stato di un'operazione di upgrade della versione principale del database sul posto mentre è in andamento.

La procedura di upgrade include le seguenti fasi:

  • ALLOYDB_PRECHECK
  • PG_UPGRADE_CHECK
  • PREPARE_FOR_UPGRADE
  • PRIMARY_INSTANCE_UPGRADE
  • READ_POOL_INSTANCES_UPGRADE
  • ROLLBACK(solo in caso di errore prima degli upgrade dei pool di lettura)
  • CLEANUP

I possibili stati di queste fasi sono:

  • NOT_STARTED
  • IN_PROGRESS
  • SUCCESS
  • FAILED
  • CANCEL_IN_PROGRESS
  • CANCELLED

Annullamenti di upgrade

Puoi annullare l'operazione di upgrade fino a un determinato punto durante l'upgrade dell'istanza principale. Una volta superato questo punto, non potrai annullare un upgrade.

Nella console Google Cloud, l'operazione non è annullabile se il pulsante Annulla upgrade non è selezionabile. Utilizzando Google Cloud CLI o l'API REST, puoi determinare se puoi annullare l'upgrade controllando upgradeClusterStatus nello stato dell'upgrade:

  • Se cancellable è true, puoi annullare l'upgrade.
  • Se cancellable è false o non è presente nello stato, non puoi annullare l'upgrade.

Backup automatici prima e dopo l'upgrade

Quando esegui un upgrade della versione principale, AlloyDB crea automaticamente i seguenti backup continui, dove XX è la versione principale di origine e YY è la versione principale di destinazione.

  • Il backup pre-upgrade viene creato immediatamente prima dell'inizio dell'upgrade. Il nome di questo backup è nel formato pre-upgrade-bkp-pgXX-pgYY-<uuid>. Puoi utilizzare questo backup per ripristinare lo stato precedente all'upgrade. Tieni presente che il ripristino non è un'operazione in situ e che viene creato un nuovo cluster.
  • Il backup post-upgrade viene creato dopo l'upgrade dell'istanza principale. Il nome di questo backup è nel formato post-upgrade-bkp-pgXX-pgYY-<uuid>.

Un backup continuo è incrementale, il che significa che memorizza solo i dati modificati rispetto al backup continuo precedente. Questo approccio consente di ridurre le dimensioni e il costo (in risorse) del backup e di velocizzare la procedura di creazione del backup. Per ulteriori informazioni, consulta la panoramica del backup e del recupero dei dati.

Quando visualizzi l'elenco dei backup, i backup di upgrade sono elencati con il tipo CONTINUOUS. Per ulteriori informazioni, consulta la sezione Visualizzare un elenco di backup.

L'esecuzione del recupero point-in-time (PITR) richiede che sia disponibile un backup di una versione. Il recupero non è disponibile sul cluster di cui è stato eseguito l'upgrade fino al completamento del backup post-upgrade o di un altro backup avviato dopo l'upgrade dell'istanza principale.

Passaggi successivi