Aggiornamenti delle versioni principali in Database di Azure per PostgreSQL - Server flessibile

Il server flessibile Database di Azure per PostgreSQL supporta PostgreSQL versioni 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 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 non sono retrocompatibili con le applicazioni esistenti.

Il server flessibile Database di Azure per PostgreSQL dispone di una funzionalità che esegue un aggiornamento della versione principale sul posto del server. 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 dell'aggiornamento (anteprima)

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

I controlli di convalida dell'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. Eseguire i 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 dell'aggiornamento sono stati completati correttamente e non sono stati identificati problemi che bloccano l'aggiornamento.
• Rilevati problemi di blocco: i controlli di convalida dell'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 i controlli di convalida dell'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 Eseguire i controlli di convalida dell'aggiornamento (anteprima).

Processo di aggiornamento

Ecco alcune considerazioni importanti per gli aggiornamenti delle versioni principali sul posto:

• Prima di avviare l'aggiornamento, assicurarsi che il server disponga di almeno 10-20% 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, il server flessibile Database di Azure per PostgreSQL esegue una procedura di controllo preliminare per identificare eventuali problemi che potrebbero causare un errore 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, il 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 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 in-place di una versione major di un server configurato per l'alta disponibilità (HA), il servizio disattiva l'HA, esegue l'aggiornamento sul server primario e quindi riattiva l'HA 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 sul posto della versione principale di un 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.
• Proteggere il server Database di Azure per PostgreSQL. Dopo un aggiornamento della versione principale in un server flessibile Database di Azure per PostgreSQL, il primo utente creato nel server, a cui viene concessa l'opzione ADMIN, dispone ora di 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, il processo di aggiornamento si arresta e visualizza un messaggio di errore dettagliato. Le limitazioni note seguenti possono causare un errore o un comportamento imprevisto dell'aggiornamento:

Configurazioni del server non supportate

• La replica geografica in Database di Azure per PostgreSQL non è supportata durante gli aggiornamenti sul posto. 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 il server flessibile possa inviare e 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 limitano questo traffico, la disponibilità elevata non viene riabilitata automaticamente dopo l'aggiornamento. Potrebbe essere necessario aggiornare manualmente le regole NSG e riattivare l'HA.
• Le visualizzazioni dipendenti da pg_stat_activity non sono supportate durante gli aggiornamenti delle versioni principali.
• Se si esegue l'aggiornamento da PostgreSQL 11 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 autenticazione.

Limitazioni delle estensioni

Gli aggiornamenti delle versioni principali sul posto non supportano tutte le estensioni PostgreSQL. L'aggiornamento non riesce durante il controllo preliminare se è presente un'estensione bloccata in un percorso di aggiornamento interessato. La maggior parte dei blocchi si applica a specifiche versioni di destinazione (e talvolta di origine) anziché a ogni aggiornamento, come indicato negli elenchi seguenti.

• Le seguenti estensioni bloccano un aggiornamento della versione major eseguito sul posto su tutti i percorsi di aggiornamento. Rimuoverli prima dell'aggiornamento e riabilitarli dopo, se supportati nella versione di destinazione: session_variable, anon, age.

• Le estensioni seguenti sono estensioni di utilità non persistenti e devono essere eliminate prima dell'aggiornamento e ricreate dopo la progettazione (tutti i percorsi di aggiornamento): pg_repack, , hypopgpg_partman.

• Le estensioni seguenti vengono bloccate solo in percorsi di versione specifici. Rimuoverli prima dell'aggiornamento se l'aggiornamento corrisponde alla condizione elencata e riabilitarli dopo se supportato nella versione di destinazione:

  Estensione	Bloccato quando
  pg_hint_plan	La versione di destinazione è PostgreSQL 14
  semver	La versione di destinazione è PostgreSQL 16 o 17
  azure_local_ai	La versione di destinazione è PostgreSQL 17 o 18
  pg_failover_slots	La versione di destinazione è PostgreSQL 17 o 18 (libreria di precaricamento condiviso)
  azure_ai	La versione di destinazione è PostgreSQL 18
  azure_storage	La versione di destinazione è PostgreSQL 18
  pg_diskann	La versione di destinazione è PostgreSQL 18
  pgrouting	La versione di destinazione è PostgreSQL 15; o l'origine è precedente a PostgreSQL 16 e la destinazione è PostgreSQL 16 o versione successiva; o la versione di destinazione è PostgreSQL 18
  orafce	La versione di origine è PostgreSQL 11, 12 o 13

• Le estensioni seguenti vengono bloccate quando altri oggetti di database dipendono dai relativi oggetti, perché in caso contrario l'aggiornamento avrà esito negativo. Risolvere le dipendenze prima dell'aggiornamento:

  • pg_stat_statements: bloccato quando altri oggetti dipendono dalla relativa vista o funzione, che causerebbe ALTER EXTENSION pg_stat_statements UPDATE un errore. Rimuovere prima gli oggetti dipendenti.
  • pgcrypto: se installato nello schema pg_catalog e durante l'aggiornamento da PostgreSQL 11 o 12 a PostgreSQL 13 o versioni successive, viene bloccato quando gli oggetti del cliente dipendono da esso (un conflitto con la funzione predefinita gen_random_uuid()). Rilocare prima l'estensione in un altro schema o eliminare gli oggetti dipendenti.

Considerazioni specifiche di PostGIS

Se si usano PostGIS o eventuali estensioni dipendenti, configurare il search_path parametro in modo da includere:

• Schemi correlati a PostGIS
• Estensioni dipendenti, tra cui: postgis, postgis_rasterpostgis_sfcgal, , postgis_tiger_geocoder, postgis_topologyaddress_standardizer, , address_standardizer_data_usfuzzystrmatch
• Se search_path non viene configurato correttamente, l'aggiornamento può non riuscire o danneggiare gli oggetti dopo l'aggiornamento.

Considerazioni specifiche di TimescaleDB

Se si usa TimescaleDB, gli aggiornamenti delle versioni principali sul posto sono supportati solo per specifiche combinazioni di origine e versione di destinazione di PostgreSQL:

Se il percorso di aggiornamento di TimescaleDB non è elencato nella matrice delle versioni supportate, l'aggiornamento in-place della versione major è bloccato. Per procedere, eliminare l'estensione TimescaleDB prima dell'aggiornamento, se possibile, oppure usare un approccio di migrazione alternativo, ad esempio la migrazione side-by-side con la replica logica.

Assicurarsi che le versioni di origine e di destinazione siano incluse nella matrice supportata prima di avviare 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 possono fare riferimento a cataloghi di sistema che cambiano tra le versioni maggiori. Eliminare tutti gli EVENT TRIGGERelementi prima dell'aggiornamento e quindi ricrearli dopo l'aggiornamento per garantire un aggiornamento senza problemi.
• Oggetti di grandi dimensioni (LO): il modo in cui un aggiornamento gestisce i database che contengono milioni di oggetti di grandi dimensioni (archiviati in pg_largeobject) dipende dalla versione principale di destinazione:
  • Destinazione PostgreSQL 15 o versione successiva: l'aggiornamento usa un metodo bulk ottimizzato per trasferire metadati di oggetti di grandi dimensioni, quindi l'utilizzo di memoria e disco temporaneo non viene più ridimensionato con il numero di oggetti di grandi dimensioni. I database con decine o centinaia di milioni di oggetti di grandi dimensioni vengono aggiornati in modo affidabile senza una preparazione aggiuntiva. Non è necessario eseguire vacuumlo o potenziare il server in anticipo per ovviare all'elevato volume di oggetti di grandi dimensioni, anche se puoi comunque eseguire vacuumlo per rimuovere oggetti di grandi dimensioni inutilizzati per altri motivi.
  • Destinazione PostgreSQL 14 o versioni precedenti: i database con milioni di oggetti di grandi dimensioni possono causare errori di aggiornamento a causa di un utilizzo elevato della memoria o del volume di log. Usare l'utilità vacuumlo per pulire gli oggetti di grandi dimensioni inutilizzati e valutare la possibilità di aumentare le prestazioni del server prima dell'aggiornamento se molti oggetti di grandi dimensioni 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. Esaminare i log durante e dopo l'aggiornamento per tenere traccia dello stato di avanzamento, diagnosticare gli errori o i ritardi e identificare i problemi di blocco in modo da poter intervenire rapidamente.

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 Scaricare PostgreSQL e aggiornare i log .

Contenuti correlati

• Aggiornamento della versione principale
• Eseguire i controlli di convalida dell'aggiornamento (anteprima)