Condividi tramite

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.

Annotazioni

Azure Database per PostgreSQL supporta gli aggiornamenti di versione principale in locale solo alle versioni PostgreSQL attualmente supportate. Ad esempio, è possibile aggiornare la versione corrente in base alla versione di destinazione supportata ufficialmente da Azure al momento dell'aggiornamento. Le versioni non supportate non possono essere selezionate come destinazioni di aggiornamento e il tentativo di eseguire l'aggiornamento a una versione deprecata può causare un errore o un'interruzione del servizio. Consultare sempre i criteri di controllo delle versioni di Azure PostgreSQL e la documentazione sull'aggiornamento prima di avviare un aggiornamento della versione principale.

Annotazioni

Gli aggiornamenti di versione principali a PostgreSQL 18 vengono abilitati in fasi. Al momento, MVU to PostgreSQL 18 è disponibile nelle aree NorthCentralUS e WestCentralUS.

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.
  • 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.
  • Un aggiornamento della versione principale sul posto è un'operazione offline, ovvero il server non sarà disponibile durante il processo. Mentre la maggior parte degli aggiornamenti viene completata in meno di 15 minuti, la durata effettiva dipende dalle dimensioni e dalla complessità del database. In particolare, il tempo necessario è direttamente proporzionale al numero di oggetti (tabelle, indici, schemi) nell'istanza di PostgreSQL. Gli schemi più grandi o più complessi possono richiedere 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. Tuttavia, è possibile eseguire un ripristino temporizzato (PITR) prima dell'aggiornamento per ripristinare la versione precedente dell'istanza del database.
  • 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 non sono supportati durante gli aggiornamenti sul posto delle versioni principali.
  • I server che usano l'archiviazione SSDv2 non sono idonei per gli aggiornamenti delle versioni principali.
  • 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, dblinkorafce, , 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, 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

Nota: Se una di queste estensioni viene visualizzata nel parametro del azure.extensions server, l'aggiornamento verrà bloccato. Rimuoverli dal parametro prima di avviare l'aggiornamento.

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.

Avvertimento

Prestare attenzione con vacuumlo. vacuumlo identifica gli oggetti di grandi dimensioni orfani in base alle colonne di riferimento convenzionali (oid, lo). Se l'applicazione usa tipi di riferimento personalizzati o indiretti, è possibile eliminare erroneamente oggetti di grandi dimensioni validi. Inoltre, vacuumlo può consumare una quantità significativa di CPU, memoria e IOPS, in particolare nei database con milioni di oggetti di grandi dimensioni. Eseguirlo durante le finestre di manutenzione e testarlo prima su un ambiente non produttivo.

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

I log di aggiornamento della versione principale (PG_Upgrade_Logs) forniscono l'accesso diretto ai log dettagliati del server. L'integrazione di PG_Upgrade_Logs nel processo di aggiornamento consente di garantire una transizione più uniforme e più trasparente alle nuove versioni di PostgreSQL.

È possibile configurare i log di aggiornamento della versione principale nello stesso modo dei log del server usando i parametri del server seguenti:

  • Per abilitare la funzionalità, impostare logfiles.download_enable su ON.
  • Per definire la conservazione dei file di log in giorni, usare logfiles.retention_days.

Log di aggiornamento della configurazione

Per iniziare a usare PG_Upgrade_Logs, è possibile configurare l'acquisizione dei log del server PostgreSQL e dei log di aggiornamento della versione principali.

È possibile accedere ai log di aggiornamento tramite l'interfaccia utente per i log del server. È possibile monitorare lo stato di avanzamento e i dettagli degli aggiornamenti delle versioni principali di PostgreSQL in tempo reale. Questa interfaccia utente fornisce una posizione centralizzata per la visualizzazione dei log, in modo da poter tenere traccia e risolvere più facilmente il processo di aggiornamento.

Vantaggi dell'uso dei log di aggiornamento

  • Diagnostica dettagliata: PG_Upgrade_Logs fornisce informazioni dettagliate preziose sul processo di aggiornamento. Acquisisce informazioni dettagliate sulle operazioni eseguite ed evidenzia eventuali errori o avvisi che si verificano. Questo livello di dettaglio è fondamentale nella diagnosi e nella risoluzione dei problemi che possono verificarsi durante l'aggiornamento, per una transizione più fluida.
  • Risoluzione dei problemi semplificata: con accesso diretto a questi log, è possibile identificare e risolvere rapidamente potenziali ostacoli di aggiornamento, ridurre i tempi di inattività e ridurre al minimo l'impatto sulle operazioni. I log fungono da strumento cruciale per la risoluzione dei problemi, rendendola più efficiente ed efficace.

Annotazioni

Gli aggiornamenti delle versioni principali sul posto sono supportati nei server con integrazione automatica. Dopo aver completato l'aggiornamento della versione principale sul posto in un server con integrazione automatica, il formato del nome utente username@servername non sarà più supportato. È invece necessario usare il formato standard: nome utente. Per evitare problemi di autenticazione, esaminare attentamente e aggiornare tutte le stringhe di connessione nelle applicazioni e negli script per assicurarsi che usino il formato del nome utente aggiornato dopo l'aggiornamento.

Contenuto correlato

  • Last updated on