Condividi tramite

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

  • Articolo

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

Il server flessibile di Database di Azure per PostgreSQL supporta le versioni 16, 15, 14, 13, 12, 11 e 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 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

Ecco alcune delle considerazioni importanti relative agli aggiornamenti delle versioni principali sul posto:

  • Durante il processo di aggiornamento della versione principale sul posto, il 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 incompatibilità, viene creato un evento del log che indica che il controllo preliminare dell'aggiornamento non è riuscito, insieme a un messaggio di errore.

    Se il controllo preliminare ha esito positivo, il server flessibile di Database di Azure per PostgreSQL arresta il servizio ed 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 sul posto di un server abilitato per la disponibilità elevata, il servizio disabilita la disponibilità elevata, esegue l'aggiornamento sul server primario e quindi riabilita 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 della versione principale sul posto per il server flessibile di Database di Azure per PostgreSQL distribuisce automaticamente la versione secondaria supportata più recente.

  • 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 fallisce, 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/la migrazione

Al termine dell'aggiornamento della versione principale, è consigliabile eseguire il comando ANALYZE in ogni database per aggiornare la tabella pg_statistic. In caso contrario, è possibile che si verifichino 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 i log tramite il portale di Azure o l'interfaccia della riga di comando di Azure. Scegliere il metodo più adatto al flusso di lavoro.

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

Limiti

Se le operazioni di controllo preliminare non riescono per un aggiornamento della versione principale sul posto, l'aggiornamento ha esito negativo e viene visualizzato un messaggio di errore dettagliato per tutte le limitazioni seguenti:

  • Gli aggiornamenti delle versioni principali sul posto attualmente non supportano le repliche in lettura. Se si dispone di un server che funge da replica in lettura, è necessario eliminare la replica prima di eseguire l'aggiornamento nel server primario. Dopo l'aggiornamento, è possibile ricreare la replica.

  • Database di Azure per PostgreSQL: il server flessibile richiede la possibilità di inviare e ricevere traffico verso le porte di destinazione 5432 e 6432 all'interno della rete virtuale in cui viene distribuito il server flessibile e in Archiviazione di Azure per l'archiviazione dei log.

    Se si configurano gruppi di sicurezza di rete (NSG) per limitare il traffico verso o dal server flessibile all'interno della subnet distribuita, assicurarsi di consentire il traffico verso le porte di destinazione 5432 e 6432 all'interno della subnet. Consentire il traffico ad Archiviazione di Azure usando il tag del servizio Archiviazione di Azure come destinazione.

    Se le regole di rete non sono configurate correttamente, la disponibilità elevata non viene abilitata automaticamente dopo un aggiornamento della versione principale ed è necessario abilitarla manualmente. Modificare le regole del gruppo di sicurezza di rete per consentire il traffico per le porte e l'archiviazione di destinazione e per abilitare una funzionalità a disponibilità elevata nel server.

  • L'aggiornamento della versione principale sul posto non supporta determinate estensioni ed esistono alcune limitazioni per l'aggiornamento di determinate estensioni. Le estensioni seguenti non sono supportate per tutte le versioni di PostgreSQL: Timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw.

  • Quando si aggiornano i server con l'estensione PostGIS installata, impostare il parametro del server search_path in modo da includere in modo esplicito:

    • Schemi dell'estensione PostGIS.
    • Estensioni che dipendono da PostGIS.
    • Estensioni che fungono da dipendenze per le estensioni seguenti: postgis, postgis_raster, postgis_sfcgal, postgis_tiger_geocoder, postgis_topology, address_standardizer, address_standardizer_data_us, fuzzystrmatch (obbligatorio per postgis_tiger_geocoder).

  • I server configurati con slot di replica logica non sono supportati.

  • I server che usano l'archiviazione SSDv2 non supportano gli aggiornamenti delle versioni principali.

Passaggi successivi