Condividi tramite


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

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Il database di Azure per PostgreSQL supporta il server flessibile PostgreSQL versioni 17 (anteprima), 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. Il server flessibile di 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.

Il server flessibile di Database di Azure per PostgreSQL include una funzionalità che consente l'aggiornamento in loco della versione principale del server con un semplice click. 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

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

  • Durante il processo di aggiornamento della versione principale in loco, Azure Database per PostgreSQL - Server Flessibile esegue una procedura di controllo preliminare per identificare eventuali problemi che potrebbero provocare un fallimento 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, Database di Azure per PostgreSQL server flessibile 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.

  • Il 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 sul posto per una nuova versione principale del server flessibile di Azure Database per PostgreSQL distribuisce automaticamente l'ultima versione secondaria supportata.

  • Un aggiornamento della versione principale sul posto è un'operazione offline che comporta un breve periodo di inattività. Il tempo di inattività è in genere inferiore a 15 minuti. La durata può variare, a seconda del numero di tabelle di sistema coinvolte.

  • 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.

  • Il 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 nel server flessibile del Database di Azure per PostgreSQL, il primo utente creato nel server, a cui viene concessa l'opzione AMMINISTRATORE avrà privilegi amministrativi su altri ruoli per le operazioni di manutenzione essenziali.

Dopo l'aggiornamento

Al termine dell'aggiornamento della versione principale, è consigliabile eseguire il ANALYZE comando in ogni database per aggiornare la pg_statistic tabella. In caso contrario, potrebbero verificarsi problemi di prestazioni.

postgres=> analyze;
ANALYZE

Log di aggiornamento della versione principale

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.

Configurazione dei log di aggiornamento

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.

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 diretti. È necessario eliminare la replica di lettura prima di aggiornare il server primario. Dopo l'aggiornamento, è possibile ricreare la replica.
  • Le regole del traffico di rete possono bloccare le operazioni di aggiornamento.
    • Verificare che il server flessibile possa inviare/ricevere traffico sulle porte 5432 e 6432 all'interno della sua rete virtuale e verso Azure Storage (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 l'alta disponibilità.
  • Gli slot di replica logica non sono supportati durante gli aggiornamenti diretti 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.

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 non sono supportate in tutte le versioni di PostgreSQL: timescaledb, pgaudit, dblinkorafce, , pg_partmanpostgres_fdw
  • Le estensioni seguenti non sono supportate quando la destinazione di aggiornamento è PostgreSQL 16 o versione successiva: pgrouting
  • Le estensioni seguenti non sono supportate durante l'aggiornamento a PostgreSQL 17: pgrouting, azure_aiage, hllpg_diskann

Queste estensioni devono essere rimosse dal parametro del server azure.extensions prima dell'aggiornamento. Se presente, l'aggiornamento verrà bloccato.

PostGIS-Specific Considerazioni

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.

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.