Aggiornamenti delle versioni principali in Database di Azure per PostgreSQL

L'istanza di server flessibile di Azure Database per PostgreSQL supporta le 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'istanza di Azure Database per PostgreSQL server flessibile aggiorna periodicamente le versioni minori 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.

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 possono 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 di Database di Azure per PostgreSQL esegue una procedura di pre-controllo 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, l'istanza del server flessibile di 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 per ripristinare l'istanza del database alla versione precedente in caso di errore di aggiornamento.
• Un'istanza del server flessibile di 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. Per riattivare l'alta disponibilità è necessaria una 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 in loco della versione principale per un'istanza del server flessibile di Azure Database per PostgreSQL distribuisce automaticamente la versione minore 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 possono 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 del Database di Azure per PostgreSQL esegue uno snapshot del database durante un aggiornamento. Lo snapshot viene creato prima dell'avvio dell'aggiornamento. Se l'aggiornamento non riesce, il sistema ripristina automaticamente lo stato del database dallo snapshot.
• PostgreSQL 16 introduce misure di sicurezza basate sui ruoli. Dopo un aggiornamento della versione principale in un'istanza del server flessibile di 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 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 possono bloccare le operazioni di aggiornamento.
  • Assicurarsi che l'istanza del server flessibile sia in grado di inviare/ricevere traffico sulle porte 5432 e 6432 nella sua rete virtuale e ad Azure Storage (necessario per l'archiviazione dei log).
  • Se i gruppi di sicurezza di rete (NSG) limitano questo traffico, la HA non si abiliterà nuovamente automaticamente dopo l'aggiornamento. Potrebbe essere necessario aggiornare manualmente le regole del gruppo di sicurezza di rete e riabilitare la disponibilità elevata.
• Gli slot di replica logica devono essere eliminati prima di eseguire un aggiornamento in loco della versione principale. È possibile ricrearli al termine dell'aggiornamento.
• Le viste 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 dell'estensione

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_fdw.
• 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 per PostGIS

Se si usano PostGIS o eventuali estensioni dipendenti, è necessario configurare il parametro del server 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 eventi: I pre-controlli di aggiornamento bloccano i trigger di eventi perché si agganciano ai comandi DDL e possono fare riferimento a cataloghi di sistema che cambiano tra le versioni principali - eliminare tutti i file EVENT TRIGGER prima dell'aggiornamento e ricrearli 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, è consigliabile 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.
• Disponibilità elevata in Database di Azure per PostgreSQL.
• Eseguire il backup e il ripristino in Database di Azure per PostgreSQL.