Aggiornamenti delle versioni principali in Database di Azure per PostgreSQL

L'istanza del server flessibile di Database di Azure per PostgreSQL supporta le versioni di PostgreSQL 18, 17, 16, 15, 14, 13, 12, 11. La community di Postgres rilascia una nuova versione principale che contiene nuove funzionalità circa una volta all'anno. Inoltre, ogni versione principale riceve correzioni periodiche di bug sotto forma di versioni secondarie. Gli aggiornamenti delle versioni secondarie includono modifiche compatibili con le applicazioni esistenti. Un'istanza del server flessibile Database di Azure per PostgreSQL aggiorna periodicamente le versioni secondarie durante la finestra di manutenzione di un cliente.

Gli aggiornamenti delle versioni principali sono più complessi rispetto a quelli delle versioni secondarie. Possono includere modifiche interne e nuove funzionalità che potrebbero non essere compatibili con le applicazioni esistenti.

L'istanza del server flessibile di Database di Azure per PostgreSQL include una funzionalità che esegue un aggiornamento della versione principale sul posto del server con un semplice clic. Questa funzionalità semplifica il processo di aggiornamento riducendo al minimo l'interruzione per utenti e applicazioni che accedono al server.

Gli aggiornamenti sul posto mantengono il nome del server e altre impostazioni del server corrente dopo l'aggiornamento di una versione principale. Non richiedono la migrazione dei dati o le modifiche alle stringhe di connessione dell'applicazione. Gli aggiornamenti sul posto sono più veloci e comportano tempi di inattività più brevi rispetto alla migrazione dei dati.

Controlli di convalida pre-aggiornamento (anteprima)

Database di Azure per PostgreSQL server flessibile fornisce controlli di convalida pre-aggiornamento (PVC) per valutare l'idoneità dell'aggiornamento prima di avviare un aggiornamento della versione principale.

I controlli di convalida pre-aggiornamento eseguono una serie di convalide di compatibilità e configurazione sul server per identificare le condizioni che potrebbero causare un errore o un comportamento imprevisto dell'aggiornamento. I controlli comuni includono estensioni non supportate, slot di replica logica, transazioni preparate, trigger di eventi, dipendenze di oggetti non supportate e modifiche di configurazione necessarie per il riavvio in sospeso.

Il processo di convalida è progettato per valutare l'idoneità dell'aggiornamento senza avviare l'operazione di aggiornamento effettiva. Gli stessi controlli di convalida vengono eseguiti automaticamente anche durante il flusso di lavoro principale di aggiornamento della versione. Questi controlli non modificano la versione del server, attivano tempi di inattività o riavviano il server. È consigliabile eseguire controlli di convalida prima di pianificare una finestra di aggiornamento di produzione.

Al termine della convalida, viene restituito uno dei risultati seguenti:

• Non sono stati rilevati problemi di blocco: i controlli di convalida pre-aggiornamento sono stati completati correttamente e non sono stati identificati problemi che bloccano l'aggiornamento.
• Rilevati problemi di blocco: i controlli di convalida pre-aggiornamento hanno identificato uno o più problemi che devono essere risolti prima che l'aggiornamento possa continuare.

A seconda dei risultati, è possibile procedere con l'aggiornamento o correggere i problemi segnalati ed eseguire nuovamente la convalida.

Limitations

Quando si usano controlli di convalida pre-aggiornamento, considerare le limitazioni seguenti:

• Lo stato del server deve essere Pronto.
• I controlli di convalida non sono supportati nelle repliche in lettura.
• La convalida non può essere eseguita mentre è già in corso un'altra operazione del server.
• I controlli di convalida richiedono la connettività a tutti i database nel server. I database non reattivi o inaccessibili possono causare errori di convalida.
• Anche se i controlli di convalida non causano tempi di inattività, è consigliabile eseguirli durante periodi di attività di database inferiori.

Per istruzioni dettagliate, vedere Come eseguire controlli di convalida pre-aggiornamento.

Processo di aggiornamento

Ecco alcune delle considerazioni importanti per gli aggiornamenti delle versioni principali in loco.

• Prima di avviare l'aggiornamento, assicurarsi che il server disponga di almeno il 10-20% dello spazio di archiviazione disponibile. Durante il processo di aggiornamento, i file di log temporanei e le operazioni sui metadati potrebbero aumentare l'utilizzo del disco. Lo spazio disponibile insufficiente può causare errori di aggiornamento o problemi di rollback.
• Durante il processo di aggiornamento della versione principale sul posto, l'istanza del server flessibile Database di Azure per PostgreSQL esegue una procedura di controllo preliminare per identificare eventuali problemi che potrebbero causare l'esito negativo dell'aggiornamento.
  • Se il controllo preliminare rileva eventuali incompatibilità, crea un evento di log che indica che la verifica preliminare dell'aggiornamento non è riuscita, insieme a un messaggio di errore.
  • Se il controllo preliminare ha esito positivo, l'istanza del server flessibile Database di Azure per PostgreSQL arresta il servizio e esegue un backup implicito subito prima di avviare l'aggiornamento. Il servizio può usare questo backup implicito per ripristinare l'istanza del database alla versione precedente in caso di errore di aggiornamento.
• Un'istanza del server flessibile Database di Azure per PostgreSQL usa lo strumento pg_upgrade per eseguire aggiornamenti delle versioni principali sul posto. Il servizio offre la flessibilità necessaria per ignorare le versioni ed eseguire l'aggiornamento direttamente alle versioni successive.
• Durante un aggiornamento della versione principale in loco di un server con disponibilità elevata, il servizio disattiva la disponibilità elevata, esegue l'aggiornamento sul server primario e quindi riattiva la disponibilità elevata al termine dell'aggiornamento. La riabilitazione della disponibilità elevata richiede capacità sufficiente per effettuare il provisioning di una nuova istanza di standby.
• La maggior parte delle estensioni viene aggiornata automaticamente alle versioni successive durante un aggiornamento della versione principale sul posto, con alcune eccezioni.
• Il processo di aggiornamento della versione principale in loco per un'istanza del server flessibile di Database di Azure per PostgreSQL distribuisce automaticamente la versione secondaria supportata più recente.
• La durata dell'aggiornamento dipende dalle dimensioni e dalla complessità del database, tra cui il numero di oggetti (tabelle, indici, schemi), oggetti di grandi dimensioni ed estensioni. I carichi di lavoro più grandi o più complessi potrebbero riscontrare tempi di aggiornamento più lunghi.
• Le transazioni a esecuzione prolungata o un carico di lavoro elevato prima dell'aggiornamento potrebbero aumentare il tempo necessario per arrestare il database e aumentare il tempo di aggiornamento.
• Dopo l'esito positivo di un aggiornamento della versione principale sul posto, non esistono modi automatizzati per ripristinare la versione precedente. È possibile eseguire un ripristino point-in-time (PITR) su una versione precedente prima dell'aggiornamento per ripristinare la versione precedente in un nuovo server.
• L'istanza del server flessibile di Database di Azure per PostgreSQL esegue un backup implicito del tuo database durante l'aggiornamento. Il backup implicito viene eseguito prima dell'avvio dell'aggiornamento. Se l'aggiornamento non riesce, il sistema ripristina automaticamente lo stato del database dal backup implicito.
• PostgreSQL 16 introduce misure di sicurezza basate sui ruoli. Dopo un aggiornamento della versione principale in un'istanza del server flessibile Database di Azure per PostgreSQL, il primo utente creato nel server, a cui viene concessa l'opzione ADMIN, avrà ora privilegi amministrativi su altri ruoli per le operazioni di manutenzione essenziali.

Considerazioni e limitazioni per l'aggiornamento

Se un'operazione di controllo preliminare non riesce durante un aggiornamento della versione principale sul posto, l'aggiornamento viene bloccato con un messaggio di errore dettagliato. Di seguito sono riportate le limitazioni note che possono causare un errore o un comportamento imprevisto dell'aggiornamento:

Configurazioni del server non supportate

• Le repliche in lettura non sono supportate durante gli aggiornamenti sul database esistente. Prima di aggiornare il server primario, è necessario eliminare la replica di lettura (incluse le repliche in lettura a catena). Dopo l'aggiornamento, è possibile ricreare la replica.
• Le regole del traffico di rete potrebbero bloccare le operazioni di aggiornamento.
  • Assicurarsi che l'istanza del server flessibile possa inviare/ricevere traffico sulle porte 5432 e 6432 all'interno della rete virtuale e a Archiviazione di Azure (per l'archiviazione dei log).
  • Se i Gruppi di sicurezza di rete (NSG) limitano questo traffico, HA non verrà riattivata automaticamente dopo l'aggiornamento. Potrebbe essere necessario aggiornare manualmente le regole NSG e riattivare l'HA.
• Gli slot di replica logica devono essere eliminati prima di eseguire un aggiornamento della versione principale sul posto. È possibile ricrearli al termine dell'aggiornamento.
• Le visualizzazioni dipendenti da pg_stat_activity non sono supportate durante gli aggiornamenti delle versioni principali.
• Se si esegue l'aggiornamento da PG11 a una versione successiva, è prima necessario configurare il server flessibile per l'uso dell'autenticazione SCRAM abilitando SCRAM e reimpostando tutte le password del ruolo di accesso.

Limitazioni delle estensioni

Gli aggiornamenti delle versioni principali sul posto non supportano tutte le estensioni PostgreSQL. L'aggiornamento avrà esito negativo durante il controllo preliminare se vengono trovate estensioni non supportate.

• Le estensioni seguenti sono supportate per l'uso normale, ma bloccano un aggiornamento della versione principale direttamente, se presente. Rimuoverli prima dell'aggiornamento e riabilitarli dopo, se supportati nella versione di destinazione: timescaledb, postgres_fdwsession_variable, pg_hint_planplv8.
• Le estensioni seguenti sono estensioni di utilità non persistenti e devono essere eliminate e ricreate dopo l'aggiornamento per impostazione predefinita: pg_repack, hypopg.
• Quando si esegue l'aggiornamento a PostgreSQL 17 e versioni successive, le estensioni seguenti non sono supportate e devono essere rimosse prima dell'aggiornamento. È possibile riabilitarli solo se supportati nella versione di destinazione: age, azure_ai, hllpg_diskann, , pgrouting.

Considerazioni specifiche di PostGIS

Se si usa PostGIS o qualsiasi estensione dipendente, è necessario configurare il parametro search_path per includere:

• Schemi correlati a PostGIS
• Estensioni dipendenti, tra cui: postgis, postgis_rasterpostgis_sfcgal, , postgis_tiger_geocoder, postgis_topologyaddress_standardizer, , address_standardizer_data_usfuzzystrmatch
• La mancata configurazione del search_path può causare errori di aggiornamento o oggetti interrotti dopo l'aggiornamento.

Altre considerazioni sull'aggiornamento

• Trigger di evento: il controllo preliminare dell'aggiornamento blocca i trigger di evento perché si agganciano ai comandi DDL e potrebbero fare riferimento a cataloghi di sistema che cambiano tra le versioni major: elimina tutti i EVENT TRIGGER prima dell'aggiornamento e quindi ricreali dopo l'aggiornamento per garantire un aggiornamento senza problemi.
• Oggetti di grandi dimensioni (LO): i database con milioni di oggetti di grandi dimensioni (archiviati in pg_largeobject) possono causare errori di aggiornamento a causa di un utilizzo elevato della memoria o del volume di log. Usa l'utilità vacuumlo per pulire gli LO inutilizzati e valuta la possibilità di potenziare il server prima dell'aggiornamento se molti LO sono ancora in uso.

Dopo l'aggiornamento

Al termine dell'aggiornamento della versione principale, eseguire il ANALYZE comando in ogni database per aggiornare la pg_statistic tabella. Le statistiche mancanti o non aggiornate possono causare piani di query errati, che a loro volta potrebbero compromettere le prestazioni e richiedere memoria eccessiva.

postgres=> analyze;
ANALYZE

Visualizzare i log di aggiornamento

Usare PG_Upgrade_Logs per monitorare lo stato di avanzamento dell'aggiornamento e risolvere i problemi.

Abilitare i log di aggiornamento usando i parametri del log del server

• Impostare logfiles.download_enable su ON.
• Configurare la conservazione con logfiles.retention_days.

Per iniziare, vedere Configurare l'acquisizione dei log del server PostgreSQL e i log di aggiornamento delle versioni principali .

Accedere PG_Upgrade_Logs dall'interfaccia utente dei log del server

• Esaminare PG_Upgrade_Logs durante e dopo l'aggiornamento per monitorare lo stato di avanzamento e diagnosticare errori o ritardi.
• Verificare la presenza di errori o avvisi se l'aggiornamento ha esito negativo o richiede più tempo del previsto.
• Usare i log per identificare i problemi di blocco e intraprendere rapidamente azioni correttive.

Vantaggi dell'uso dei log di aggiornamento

• Diagnosticare rapidamente i problemi: usare PG_Upgrade_Logs per esaminare ogni passaggio dell'aggiornamento e identificare errori o avvisi.
• Risolvere i problemi in modo efficiente: analizzare i log per individuare gli errori, ridurre i tempi di inattività e intraprendere azioni correttive più velocemente.

PG_Upgrade_Logs consente di comprendere cosa è accaduto durante l'aggiornamento e risolvere i problemi con fiducia.

Contenuti correlati

• Aggiornamento della versione principale.
• Controlli di convalida pre-aggiornamento.