Questo documento descrive gli upgrade in loco della versione principale del database AlloyDB per PostgreSQL, che consentono di eseguire l'upgrade di un database a una versione superiore senza eseguire la migrazione dei dati o sostituire l'istanza esistente.
La community di 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 eseguendo l'upgrade a una versione principale superiore. Puoi eseguire l'upgrade del cluster utilizzando questa funzionalità di upgrade in loco o migrando i dati in un nuovo cluster AlloyDB.
Per ulteriori informazioni, consulta le norme relative alle versioni del database.
Gli upgrade in loco della versione principale 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.
- Tutte le istanze del cluster (principale e pool di lettura) vengono aggiornate nell'ambito della stessa operazione.
Flusso di lavoro di upgrade della versione principale in loco
Quando avvii un upgrade del cluster, AlloyDB esegue le seguenti azioni:
- Esegue controlli pre-upgrade per rilevare incompatibilità che possono influire sull'upgrade.
- Si prepara all'upgrade della versione principale, che include la creazione di un clone interno del cluster.
- Rende l'istanza principale non disponibile. Il tempo senza schermo inizia. Le letture possono comunque essere eseguite tramite i pool di lettura.
- Avvia un backup pre-upgrade.
- Esegue l'upgrade dell'istanza principale.
- Rende non disponibili le istanze del pool di lettura.
- Rende disponibile l'istanza principale. Il tempo di riposo termina.
- Avvia un backup post-upgrade.
- Esegue l'upgrade delle istanze del pool di lettura.
Una volta superati i controlli pre-upgrade, il cluster viene clonato in un cluster interno nello stesso progetto. Il backup e il ripristino necessari per clonare il cluster richiedono circa 10 minuti per terabyte di dati.
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 per le letture e le scritture finché non viene eseguito l'upgrade. Il tempo di inattività previsto è in genere compreso tra 20 minuti e un'ora e dipende principalmente dallo schema del database e dal numero di oggetti.
Dopo l'upgrade dell'istanza principale, le istanze del pool di lettura diventano non disponibili. I tentativi di upgrade vengono eseguiti contemporaneamente su tutte le istanze del pool di lettura. Il tempo di inattività dovrebbe durare circa 20 minuti.
Se l'upgrade della versione principale non riesce in qualsiasi passaggio prima dell'upgrade dell'istanza principale, AlloyDB esegue automaticamente il rollback di tutte le modifiche.
Dopo l'upgrade dell'istanza primaria, la versione del cluster viene aggiornata alla versione di destinazione e non vengono attivati rollback in caso di 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 vanno a buon fine. In queste situazioni, contatta l'assistenza Google Cloud CLI.
La tabella seguente fornisce una stima approssimativa del tempo necessario per completare l'upgrade per cluster di diverse dimensioni del database:
| Dimensioni del database | Pre-upgrade (senza tempi di inattività) | Tempo di inattività principale | Tempo di inattività del pool di lettura | Durata totale |
|---|---|---|---|---|
| 100 GB | Circa 15 minuti | Circa 20 minuti | Circa 20 minuti | ~1 ora |
| 1 TB | Circa 30 minuti | Circa 20 minuti | Circa 20 minuti | Circa 1 ora e 15 minuti |
| 4 TB | ~1 ora | Circa 20 minuti | Circa 20 minuti | ~1 ora e 45 minuti |
| 16 TB | ~3 ore | Circa 20 minuti | Circa 20 minuti | ~3 ore 45 minuti |
| 32 TB | ~5 ore e 30 minuti | Circa 20 minuti | Circa 20 minuti | ~6 ore e 15 minuti |
| 64 TB | ~11 ore | Circa 20 minuti | Circa 20 minuti | ~12 ore |
| 128 TB | ~21 ore e 30 minuti | Circa 20 minuti | Circa 20 minuti | Circa 22 ore e 15 minuti |
Per ulteriori informazioni, vedi Eseguire l'upgrade in loco 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 corso.
La procedura di upgrade include le seguenti fasi:
ALLOYDB_PRECHECKPG_UPGRADE_CHECKPREPARE_FOR_UPGRADEPRIMARY_INSTANCE_UPGRADEREAD_POOL_INSTANCES_UPGRADEROLLBACK(solo in caso di errore prima degli upgrade del pool di lettura)CLEANUP
Gli stati possibili di queste fasi includono:
NOT_STARTEDIN_PROGRESSSUCCESSFAILEDCANCEL_IN_PROGRESSCANCELLED
Annullamenti degli upgrade
Puoi annullare l'operazione di upgrade fino a un certo punto durante l'upgrade dell'istanza primaria. Una volta superato questo punto, non puoi annullare un upgrade.
Nella console Google Cloud , l'operazione non è annullabile se il pulsante
Annulla upgrade è disattivato. 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èfalseo non è presente nello stato, non puoi annullare l'upgrade.
Backup automatici pre-upgrade e post-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 loco e che crea 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 il backup memorizza solo i dati modificati rispetto al backup continuo precedente. Questo approccio riduce le dimensioni e il costo (in risorse) del backup e velocizza la procedura di creazione del backup. Per ulteriori informazioni, vedi Panoramica del backup e del ripristino dei dati.
Quando visualizzi l'elenco dei backup, i backup dell'upgrade sono elencati con il tipo
CONTINUOUS. Per ulteriori informazioni, vedi
Visualizzare un elenco di backup.
L'esecuzione del recupero point-in-time (PITR) richiede la disponibilità di un backup di una versione. Il recupero non è disponibile sul cluster sottoposto ad upgrade finché non viene completato il backup post-upgrade o un altro backup avviato dopo l'upgrade dell'istanza primaria.