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:
- Esegue controlli pre-upgrade per trovare incompatibilità che possono influire sull'upgrade.
- Prepara l'upgrade della versione principale, che include la creazione di un clone interno del cluster.
- Rende l'istanza principale non disponibile. Inizia il tempo di riposo. Le letture possono essere eseguite tramite i pool di lettura.
- Avvia un backup precedente all'upgrade.
- Esegue l'upgrade dell'istanza principale.
- Le istanze del pool di lettura non sono disponibili.
- 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 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.