Share via

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

  • Articolo

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

Database di Azure per PostgreSQL server flessibile supporta PostgreSQL versioni 16, 15, 14, 13, 12 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 versioni precedenti con le applicazioni esistenti. Database di Azure per PostgreSQL server flessibile aggiorna periodicamente le versioni secondarie durante la finestra di manutenzione di un cliente.

Gli aggiornamenti delle versioni principali sono più complessi rispetto agli aggiornamenti delle versioni secondarie. Possono includere modifiche interne e nuove funzionalità che potrebbero non essere compatibili con le versioni precedenti con le applicazioni esistenti.

Database di Azure per PostgreSQL server flessibile dispone di una funzionalità che esegue un aggiornamento della versione principale sul posto del server con solo un 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 apportate alle stringa 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, Database di Azure per PostgreSQL server flessibile esegue una procedura di pre-controllo per identificare eventuali problemi che potrebbero causare un errore dell'aggiornamento.

    Se il controllo preliminare rileva eventuali 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, 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.

  • Database di Azure per PostgreSQL server flessibile usa lo strumento pg_upgrade per eseguire aggiornamenti delle versioni principali sul posto. Il servizio offre la flessibilità necessaria per ignorare le versioni e 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 Database di Azure per PostgreSQL server flessibile 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.

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 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 attivare la funzionalità, impostare su logfiles.download_enableON.
  • Per definire la conservazione dei file di log in giorni, usare logfiles.retention_days.

Installazione 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 approfondita: PG_Upgrade_Logs fornisce informazioni dettagliate 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 consentendo una risoluzione dei problemi più efficiente ed efficace.

Limiti

Se le operazioni di pre-controllo 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 alle porte di destinazione 5432 e 6432 all'interno della rete virtuale in cui viene distribuito il server flessibile e di 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 al traffico di 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 abilitare manualmente la disponibilità elevata. 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.

  • Gli aggiornamenti delle versioni principali sul posto non supportano determinate estensioni e esistono alcune limitazioni per l'aggiornamento di determinate estensioni. Le estensioni seguenti non sono supportate per tutte le versioni di PostgreSQL: Timescaledb, pgaudit, orafcedblink, , pg_partman, . postgres_fdw

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

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

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

Passaggi successivi