Disponibilità elevata (affidabilità) in Database di Azure per PostgreSQL

Questo articolo descrive la disponibilità elevata in Database di Azure per PostgreSQL, che include zone di disponibilità e ripristino tra aree e continuità aziendale. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.

Database di Azure per PostgreSQL supporta la disponibilità elevata tramite il provisioning di repliche primarie e di standby fisicamente separate, all'interno della stessa zona di disponibilità (a livello di zona) oppure tra più zone di disponibilità (con ridondanza della zona). Questo modello a disponibilità elevata è progettato per garantire che i dati di cui è stato eseguito il commit non vengano mai persi durante gli errori. In una configurazione a disponibilità elevata (HA) i dati vengono sottoposti a commit in maniera sincrona sia nel server primario che in quello di standby. Il modello è progettato in modo che il database non diventi un singolo punto di guasto nell'architettura software. Per altre informazioni sul supporto per la disponibilità elevata e la zona di disponibilità, vedere Supporto della zona di disponibilità.

Supporto della zona di disponibilità

Le zone di disponibilità sono gruppi di data center separati fisicamente all'interno di ogni area di Azure. In caso di guasto in una zona, i servizi possono passare a una delle zone restanti.

Database di Azure per PostgreSQL supporta modelli con ridondanza tra zone e modelli zonali per configurazioni ad alta disponibilità. Entrambe le configurazioni a disponibilità elevata consentono la funzionalità di failover automatico senza perdita di dati durante eventi pianificati e non pianificati.

• Con ridondanza della zona. La disponibilità elevata con ridondanza della zona distribuisce una replica di standby in un'altra zona con funzionalità di failover automatico. La ridondanza della zona offre il massimo livello di disponibilità, ma è necessario configurare la ridondanza dell'applicazione tra le zone. Per questo motivo, scegliere ridondanza della zona quando si vuole la protezione dagli errori a livello di zona di disponibilità e quando la latenza tra le zone di disponibilità è accettabile. Anche se può verificarsi un impatto sulla latenza nelle scritture e nei commit a causa della replica sincrona, ciò non influisce sulle query di lettura. Questo impatto è specifico per i carichi di lavoro, il tipo di SKU selezionato e l'area.

  È possibile scegliere l'area e le zone di disponibilità sia per i server primari che per quelli di standby. Viene effettuato il provisioning del server di replica standby nella zona di disponibilità scelta nella stessa area con una configurazione di calcolo, archiviazione e rete simile a quella del server primario. I file di dati e i file di log delle transazioni (log write-ahead, noti anche come WAL) vengono archiviati nell'archiviazione con ridondanza locale (LRS) all'interno di ogni zona di disponibilità, archiviando automaticamente tre copie di dati. Una configurazione con ridondanza della zona fornisce l'isolamento fisico dell'intero stack tra i server primari e di standby.

  

L'opzione con ridondanza zonale è disponibile solo nelle regioni che hanno supporto per le zone di disponibilità.

La ridondanza della zona non è supportata per:

• Livello di calcolo con possibilità di burst

• Aree con disponibilità a zona singola

• A livello di zona. Scegliere una distribuzione a livello di zona quando si vuole ottenere il massimo livello di disponibilità all'interno di una singola zona di disponibilità, ma con la latenza di rete più bassa. È possibile scegliere l'area e la zona di disponibilità per distribuire entrambi il server di database primario. Viene eseguito automaticamente il provisioning e la gestione di un server di replica standby nella stessa zona di disponibilità del server primario, con un ambiente calcolo, un'archiviazione e una configurazione di rete simili. Una configurazione a livello di zona protegge i database da errori a livello di nodo e consente anche di ridurre i tempi di inattività delle applicazioni durante eventi di inattività pianificati e non pianificati. I dati del server primario vengono replicati in modo sincrono nella replica di standby. se si verifica un'interruzione del server primario, il server esegue automaticamente il failover nella replica di standby.

  

L'opzione di distribuzione a livello di zona è disponibile in tutte le aree di Azure in cui è possibile distribuire Server flessibile.

Annotazioni

Entrambi modelli di distribuzione a livello di zona o con ridondanza della zona dal punto di vista architetturale si comportano allo stesso modo. Ad entrambi si applicano varie discussioni nelle sezioni seguenti, a meno che il richiamo non avvenga diversamente.

Configurare la resilienza di zona nel portale

È possibile configurare la disponibilità elevata in due modi: disponibilità elevata con ridondanza della zona, che inserisce il server di standby in una zona di disponibilità diversa per la massima resilienza o la disponibilità elevata della stessa zona, che distribuisce il server standby nella stessa zona del server primario per ridurre al minimo la latenza.

Per semplificare la configurazione e garantire la resilienza di zona, il portale offre un'opzione di resilienza zonale con due pulsanti di opzione: Abilitato e Disabilitato. Selezionando Abilitato si tenterà di creare il server di standby in una zona di disponibilità diversa (modalità disponibilità elevata con ridondanza di zona). Se l’area non supporta la disponibilità elevata con ridondanza della zona, è possibile selezionare la casella di controllo di fallback (evidenziata nell'immagine seguente) per abilitare la disponibilità elevata nella stessa zona.

Quando si seleziona la casella di controllo di fallback, il sistema crea il server standby nella stessa zona. Se la capacità di zona diventa disponibile in un secondo momento, Azure invierà una notifica in modo da poter scegliere di eseguire la migrazione a una configurazione HA ridondante a livello di zona usando il ripristino point-in-time o le repliche in lettura. Se non si seleziona la casella di controllo e la capacità della zona non è disponibile, non sarà possibile abilitare la disponibilità elevata. Questo design applica la disponibilità elevata con ridondanza della zona come impostazione predefinita, fornendo al contempo un fallback controllato per la disponibilità elevata nella stessa zona, in modo che i carichi di lavoro raggiungano alla fine la piena resilienza della zona senza intervento manuale.

Funzionalità di disponibilità elevata

• Una replica standby viene distribuita nella stessa configurazione della macchina virtuale, inclusi vCores, archiviazione e impostazioni di rete, come quella del server primario.

• È possibile aggiungere il supporto della zona di disponibilità per un server di database esistente.

• È possibile rimuovere la replica di standby disabilitando la disponibilità elevata.

• È possibile scegliere le zone di disponibilità per i server di database primario e di standby per la disponibilità con ridondanza della zona.

• Operazioni come l'arresto, l'avvio e il riavvio vengono eseguite contemporaneamente sui server di database primari e di standby.

• Nei modelli con ridondanza di zona e modelli zonali, il server di database primario effettua backup automatici periodici. Allo stesso tempo, la replica standby archivia continuamente i log delle transazioni nell'archiviazione di backup. Se l'area supporta zone di disponibilità, i dati di backup vengono archiviati nell'archiviazione con ridondanza della zona (ZRS). Nelle aree che non supportano zone di disponibilità, i dati di backup vengono archiviati nell'archiviazione con ridondanza locale (LRS).

• I client si connettono sempre al nome host finale del server di database primario.

• Tutte le modifiche apportate ai parametri del server vengono applicate anche alla replica di standby.

• È possibile riavviare il server per applicare eventuali modifiche ai parametri statici del server.

• Le attività di manutenzione periodiche, come gli aggiornamenti di versione minori, vengono eseguite prima al standby. Per ridurre i tempi di inattività, lo standby viene alzato di livello primario in modo che i carichi di lavoro possano continuare mentre le attività di manutenzione vengono applicate al nodo rimanente.

Annotazioni

Per garantire il corretto funzionamento della disponibilità elevata, configurare i valori dei parametri del server max_replication_slots e max_wal_senders. La disponibilità elevata richiede quattro di ciascuno per gestire i failover e gli upgrade senza interruzioni. Per una configurazione a disponibilità elevata con cinque repliche in lettura e 12 slot di replica logica, impostare i valori dei parametri max_replication_slots e max_wal_senders su 21. Questa configurazione è necessaria perché ogni slot di replica in lettura e di replica logica ne richiede uno ciascuno, oltre ai quattro necessari per il corretto funzionamento della disponibilità elevata. Per altre informazioni sui max_replication_slots parametri e max_wal_senders , vedere la documentazione.

Monitorare l'integrità della disponibilità elevata

Il monitoraggio dello stato di salute ad alta disponibilità in Azure Database per PostgreSQL offre una panoramica continua della salute e della prontezza delle istanze abilitate per l'alta disponibilità. Questa funzionalità di monitoraggio applica il framework RHC (Resource Health Check) di Azure per rilevare e segnalare eventuali problemi che potrebbero influire sulla disponibilità complessiva o sulla conformità del failover del database. Valutando le metriche chiave, come lo stato della connessione, lo stato di failover e l'integrità della replica dei dati, il monitoraggio della salute dell'HA consente la risoluzione proattiva dei problemi e aiuta a mantenere l'operatività e le prestazioni del database.

È possibile usare il monitoraggio dello stato di integrità della disponibilità elevata per:

• Ottenere informazioni dettagliate in tempo reale sull'integrità delle repliche primarie e di standby, con indicatori di stato che rivelano potenziali problemi, ad esempio prestazioni ridotte o blocco di rete.
• Configurare avvisi per notifiche tempestive su eventuali modifiche apportate allo stato della disponibilità elevata, in modo da poter intervenire immediatamente per risolvere potenziali interruzioni.
• Ottimizzare l'idoneità del failover identificando e risolvendo i problemi prima che influiscano sulle operazioni del database.

Per una guida dettagliata sulla configurazione e l'interpretazione degli stati di integrità di HA, consulta Monitoraggio dello stato di integrità di Alta Disponibilità per Database di Azure per PostgreSQL.

Limitazioni della disponibilità elevata

• A causa della replica sincrona nel server di standby, in particolare con una configurazione con ridondanza della zona, le applicazioni possono riscontrare un'elevata latenza di scrittura e commit.

• Non è possibile usare la replica standby per le query di lettura.

• A seconda del carico di lavoro e dell'attività nel server primario, il processo di failover potrebbe richiedere più di 120 secondi perché la replica di standby deve eseguire il ripristino prima che possa essere alzata di livello.

• Il server di standby generalmente recupera i file WAL a 40 MB/s. Per le versioni più grandi, questa velocità può aumentare fino a 200 MB/s. Se il carico di lavoro supera questo limite, è possibile riscontrare un tempo prolungato per il completamento del ripristino durante il failover o dopo aver stabilito un nuovo standby.

• Il riavvio del server di database primario riavvia anche la replica di standby.

• Non è possibile configurare un standby aggiuntivo.

• Non è possibile pianificare le attività di gestione avviate dal cliente durante la finestra di manutenzione gestita.

• Gli eventi pianificati, ad esempio il calcolo della scalabilità e la scalabilità dell'archiviazione, avvengono prima in standby e poi nel server primario. Attualmente, il server non esegue il failover per queste operazioni pianificate.

• Se si configura la decodifica logica o la replica logica su un server flessibile abilitato per la disponibilità elevata:

  • In PostgreSQL 16 e versioni precedenti gli slot di replica logica non vengono mantenuti nel server di standby dopo un failover per impostazione predefinita.
  • Per garantire che la replica logica continui a funzionare dopo il failover, è necessario abilitare l'estensione pg_failover_slots e configurare le impostazioni di supporto, hot_standby_feedback = onad esempio .
  • A partire da PostgreSQL 17, la sincronizzazione degli slot è supportata in modo nativo. Se si abilitano le configurazioni PostgreSQL corrette (sync_replication_slots, hot_standby_feedback), gli slot di replica logica vengono mantenuti automaticamente dopo il failover e non è necessaria alcuna estensione.
  • Per i passaggi di installazione e i prerequisiti, vedere la documentazione dell'estensione PG_Failover_Slots .

• La configurazione delle zone di disponibilità tra la rete privata (rete virtuale) e l'accesso pubblico con endpoint privati non è supportata. È necessario configurare le zone di disponibilità all'interno di una rete virtuale (estesa tra zone di disponibilità all'interno di un'area) o l'accesso pubblico con endpoint privati.

• È possibile configurare solo le zone di disponibilità all'interno di una singola area. Non è possibile configurare le zone di disponibilità tra aree.

SLA

• Il modello zonale offre una disponibilità per un SLA di circa il 99,95%.

• Il modello di ridondanza della zona offre una disponibilità per uno Contratto di servizio di circa 99,99%.

Creare un database di Azure per PostgreSQL con la zona di disponibilità abilitata

Per informazioni su come creare un database di Azure per PostgreSQL per la disponibilità elevata con zone di disponibilità, vedere Avvio rapido: Creare un database di Azure per PostgreSQL nel portale di Azure.

Ridistribuzione e migrazione della zona di disponibilità

Per informazioni su come abilitare o disabilitare la configurazione a disponibilità elevata nel server flessibile nei modelli di distribuzione con ridondanza zonale e modelli zonali, consultare Gestire la disponibilità elevata nel server flessibile.

Componenti e flusso di lavoro a disponibilità elevata

Completamento delle transazioni

Le operazioni di scrittura e commit attivate da una transazione dell'applicazione vengono prima registrate nel WAL nel server primario. Il server primario trasmette questi log al server di standby usando il protocollo di streaming Postgres. Quando l'archiviazione del server standby rende persistenti i log, il server primario riconosce il completamento della scrittura. L'applicazione esegue il commit della transazione solo dopo questa conferma. Questo round-trip aggiuntivo introduce latenza nell'applicazione. La percentuale di impatto dipende dall'applicazione. Questo processo di riconoscimento non attende che i log vengano applicati al server di standby. Il server standby rimane in modalità di ripristino fino a quando non viene alzato di livello.

Controllo sanitario

Il monitoraggio flessibile dell'integrità del server controlla periodicamente l'integrità dei server primari e standby. Dopo più ping, se il monitoraggio dell'integrità rileva che un server primario non è raggiungibile, il servizio avvia un failover automatico nel server di standby. L'algoritmo di monitoraggio della salute utilizza più dati per evitare situazioni di falsi positivi.

Modalità di failover

Server flessibile supporta due modalità di failover, failover pianificato e failover non pianificato. In entrambe le modalità, una volta interrotta la replica, il server standby esegue il ripristino prima della promozione a primario e viene aperto per operazioni di lettura e scrittura. Con le voci DNS automatiche aggiornate con il nuovo endpoint server primario, le applicazioni possono connettersi al server usando lo stesso endpoint. Un nuovo server di standby viene stabilito in background, in modo che l'applicazione possa mantenere la connettività.

Stato della disponibilità elevata

Il sistema monitora continuamente l'integrità dei server primari e di standby. Esegue azioni appropriate per risolvere i problemi, incluso l'attivazione di un failover nel server di standby. La tabella seguente elenca i possibili stati di disponibilità elevata:

Stato	Descrizione
Inizializzazione	Nel processo di creazione di un nuovo server di standby.
Replica dei dati	Dopo aver creato lo standby, viene aggiornato con il database primario.
Integra	La replica è in stato stabile e integra.
Esecuzione del failover	Il server di database sta eseguendo il failover nello standby.
Rimozione standby in corso	Nel processo di eliminazione del server di standby.
Non abilitato	La disponibilità elevata non è abilitata.

Annotazioni

È possibile abilitare la disponibilità elevata durante la creazione del server o in un secondo momento. Se si abilita o si disabilita la disponibilità elevata durante la fase di post-creazione, eseguire questa operazione quando l'attività del server primario è bassa.

Operazioni con stato stabile

Le applicazioni client PostgreSQL si connettono al server primario usando il nome del server di database. Il server primario gestisce direttamente le letture dell'applicazione. Allo stesso tempo, l'applicazione riceve la conferma dei commit e delle scritture solo dopo che i dati di log vengono mantenuti nel server primario e nella replica standby. A causa di questo round trip aggiuntivo, le applicazioni possono aspettarsi una latenza elevata per scritture e commit. È possibile monitorare l'integrità della disponibilità elevata nel portale.

1. I client si connettono al server flessibile ed eseguono operazioni di scrittura.
2. Le modifiche vengono replicate nel sito di standby.
3. Il primario riceve un riconoscimento.
4. Le operazioni di scrittura e i commit vengono confermati.

Ripristino temporizzato dei server a disponibilità elevata

Per i server flessibili configurati con disponibilità elevata, il sistema replica i dati di log in tempo reale nel server di standby. Eventuali errori utente nel server primario, come una cancellazione accidentale di una tabella o aggiornamenti errati dei dati, vengono replicati nella replica in standby. Non è quindi possibile usare lo standby per eseguire il ripristino da tali errori logici. Per riprendersi da tali errori, è necessario eseguire un ripristino a un punto nel tempo dal backup. Usando la funzionalità di ripristino temporizzato di un server flessibile, è possibile ripristinare l'ora prima che si sia verificato l'errore. Un nuovo server di database viene ripristinato come server flessibile a zona singola con un nuovo nome server fornito dall'utente per i database configurati con disponibilità elevata. È possibile usare il server ripristinato per diversi casi d'uso:

• Usare il server ripristinato per la produzione e, facoltativamente, abilitare la disponibilità elevata con replica standby nella stessa zona o in un'altra zona nella stessa area.

• Se si vuole ripristinare un oggetto, esportarlo dal server di database ripristinato e importarlo nel server di database di produzione.

• Se si vuole clonare il server di database per scopi di test e sviluppo o per eseguire il ripristino per qualsiasi altro scopo, è possibile eseguire il ripristino temporizzato.

Per informazioni su come eseguire un ripristino temporizzato di un server flessibile, vedere Ripristino temporizzato di un server flessibile.

Supporto del failover

Failover pianificato

Gli eventi di inattività pianificati includono aggiornamenti periodici del software pianificati di Azure e aggiornamenti delle versioni secondarie. È anche possibile usare un failover pianificato per restituire il server primario a una zona di disponibilità preferita. Quando si configura la disponibilità elevata, queste operazioni si applicano prima alla replica standby mentre le applicazioni continuano ad accedere al server primario. Dopo che il processo aggiorna la replica di standby, svuota le connessioni server primarie e attiva un failover che attiva la replica standby come server primario con lo stesso nome del server di database. Le applicazioni client si riconnettono con lo stesso nome del server di database al nuovo server primario e possono riprendere le operazioni. Il processo stabilisce un nuovo server standby nella stessa zona del database primario precedente.

Per altre operazioni avviate dall'utente, ad esempio la scalabilità del calcolo o la scalabilità dell'archiviazione, il processo applica prima le modifiche sul sistema di standby, quindi sul database primario. Attualmente, il servizio non esegue il failover nel server di standby. Di conseguenza, mentre l'operazione di scalabilità viene eseguita nel server primario, le applicazioni riscontrano brevi tempi di inattività.

È possibile usare questa funzionalità anche per eseguire il failover nel server di standby con tempi di inattività ridotti. Ad esempio, il server primario potrebbe trovarsi in una zona di disponibilità diversa rispetto all'applicazione dopo un failover non pianificato. Si vuole riportare il server primario nella zona precedente per la colocazione con l'applicazione.

Quando si esegue questa funzionalità, il processo prepara prima il server di standby per assicurarsi che venga aggiornato con le transazioni recenti, consentendo all'applicazione di continuare a eseguire operazioni di lettura e scrittura. Il processo promuove il server di standby e interrompe le connessioni al server primario. L'applicazione può continuare a scrivere nel database primario mentre il processo stabilisce un nuovo server di standby in background. Nella tabella seguente vengono descritti i passaggi necessari per il failover pianificato:

Step	Descrizione	Tempo di inattività dell'app previsto?
1	Attendere che il server di standby si sincronizzi con il server primario.	NO
2	Il sistema di monitoraggio interno avvia il flusso di lavoro di failover.	NO
3	Le scritture dell'applicazione vengono bloccate quando il server di standby è vicino al numero di sequenza log (LSN) del primario.	Yes
4	Il server di standby viene promosso a server indipendente.	Yes
5	Il record DNS viene aggiornato con l'indirizzo IP del nuovo server di standby.	Yes
6	L'applicazione si riconnette e riprende la lettura e scrittura con il nuovo primario.	NO
7	Viene stabilito un nuovo server di standby in un'altra zona.	NO
8	Il server di standby inizia a recuperare i log (dal BLOB di Azure) che ha perso rilevato durante la sua creazione.	NO
9	Viene stabilito uno stato stabile tra il server primario e quello di standby.	NO
10	Il processo di failover pianificato è completato.	NO

Il tempo di inattività dell'applicazione inizia al passaggio 3 e può riprendere l'operazione dopo il passaggio 5. Il resto dei passaggi avviene in background senza influire sulle operazioni di scrittura e commit dell'applicazione.

Suggerimento

Con un server flessibile, è possibile pianificare facoltativamente le attività di manutenzione avviate da Azure scegliendo una finestra di 60 minuti in un giorno di preferenza quando le attività nei database dovrebbero essere basse. Le attività di manutenzione di Azure, ad esempio l'applicazione di patch o gli aggiornamenti di versioni secondarie, vengono eseguite durante tale finestra. Se non si sceglie una finestra personalizzata, il sistema alloca una finestra di un'ora tra le 11.00 e le 7.00 ora locale per il server. Queste attività di manutenzione avviate da Azure vengono eseguite anche nella replica standby per server scalabili configurati con zone di disponibilità.

Per un elenco dei possibili eventi di inattività pianificati, vedere Eventi di inattività pianificati.

Failover non pianificato

I tempi di inattività non pianificati possono verificarsi a causa di interruzioni impreviste, ad esempio errori hardware sottostanti, problemi di rete e bug software. Se il server di database configurato con disponibilità elevata diventa inattivo in modo imprevisto, il processo attiva la replica di standby e i client possono riprendere le operazioni. Se non si configura la disponibilità elevata e il tentativo di riavvio non riesce, il processo effettua automaticamente il provisioning di un nuovo server di database. Anche se non è possibile evitare tempi di inattività non pianificati, il server flessibile consente di ridurre i tempi di inattività eseguendo automaticamente operazioni di ripristino senza richiedere l'intervento umano.

Per informazioni sui failover non pianificati e sui tempi di inattività, inclusi i possibili scenari, vedere Mitigazione dei tempi di inattività non pianificati.

Test di failover (failover forzato)

Con un failover forzato, è possibile simulare uno scenario di interruzione non pianificato durante l'esecuzione del carico di lavoro di produzione e osservare il tempo di inattività dell'applicazione. È anche possibile usare un failover forzato quando il server primario non risponde.

Un failover forzato causa l'arresto del server primario e avvia il flusso di lavoro di failover in cui viene eseguita l'operazione di promozione del server di standby. Dopo che lo standby completa il processo di ripristino fino all'ultimo commit dei dati, viene promosso a server primario. I record DNS vengono aggiornati e l'applicazione può connettersi al server primario promosso. L'applicazione può continuare a scrivere nel primario mentre viene stabilito un nuovo server di standby in background, che non influisce sul tempo di attività.

Nella tabella seguente vengono descritti i passaggi durante il failover forzato:

Step	Descrizione	Tempo di inattività dell'app previsto?
1	Il server primario si arresta poco dopo la ricezione della richiesta di failover.	Yes
2	L'applicazione rileva tempi di inattività perché il server primario è inattivo.	Yes
3	Il sistema di monitoraggio interno rileva l'errore e avvia un failover nel server di standby.	Yes
4	Il server di standby passa alla modalità di ripristino prima di essere completamente promosso a server indipendente.	Yes
5	Il processo di failover attende il completamento del ripristino dello standby.	Yes
6	Quando il server è attivo, il processo aggiorna il record DNS con lo stesso nome host, ma usa l'indirizzo IP dello standby.	Yes
7	L'applicazione può riconnettersi al nuovo server primario e riprendere l'operazione.	NO
8	Viene stabilito un server di standby nella zona preferita.	NO
9	Il server di standby inizia a recuperare i log (dal BLOB di Azure) che ha perso rilevato durante la sua creazione.	NO
10	Viene stabilito uno stato stabile tra il server primario e quello di standby.	NO
11	Il processo di failover forzato è stato completato.	NO

Il tempo di inattività dell'applicazione inizia dopo il passaggio 1 e continua fino al termine del passaggio 6. Gli altri passaggi vengono eseguiti in background senza influire sulle operazioni di scrittura e commit dell'applicazione.

Importante

Il processo di failover end-to-end include (a) il failover nel server di standby dopo l'errore primario e (b) la creazione di un nuovo server di standby in uno stato stabile. Quando l'applicazione comporta tempi di inattività fino al completamento del failover in standby, misurare il tempo di inattività dal punto di vista dell'applicazione/client anziché del processo di failover end-to-end complessivo.

Considerazioni sull'esecuzione di failover forzati

• Il tempo complessivo dell'operazione end-to-end può essere superiore al tempo di inattività effettivo riscontrato dall'applicazione.

  Importante

  Osservare sempre il tempo di inattività dal punto di vista dell'applicazione.

• Non eseguire failover immediati e back-to-back. Attendere almeno 15-20 minuti tra i failover, in modo che il nuovo server di standby possa essere completamente stabilito.

• Eseguire un failover forzato durante un periodo di attività ridotto per ridurre i tempi di inattività.

Procedure consigliate per le statistiche di PostgreSQL dopo il failover

Dopo un failover di PostgreSQL, la gestione delle prestazioni ottimali del database comporta la comprensione dei ruoli distinti delle tabelle pg_statistic e pg_stat_* . La pg_statistic tabella archivia le statistiche di Optimizer, fondamentali per Query Planner. Queste statistiche includono le distribuzioni dei dati all'interno delle tabelle e rimangono intatte dopo un failover, garantendo che Query Planner possa continuare a ottimizzare l'esecuzione delle query in modo efficace in base ad accurate informazioni sulla distribuzione dei dati storici.

Al contrario, le tabelle pg_stat_*, che registrano statistiche sulle attività, ad esempio il numero di analisi, tuple lette e aggiornamenti, con il failover vengono reimpostate. Un esempio di tale tabella è pg_stat_user_tables, che tiene traccia dell'attività per le tabelle definite dall'utente. Questa reimpostazione riflette in modo accurato lo stato operativo del nuovo server primario, ma implica anche la perdita di metriche di attività cronologiche che potrebbero informare il processo di svuotamento automatico e altre efficienze operative.

Tenendo conto di questa distinzione, eseguire ANALYZE dopo un failover PostgreSQL. Questa azione aggiorna le tabelle pg_stat_*, ad esempio pg_stat_user_tables, con statistiche di attività aggiornate, consentendo il processo di svuotamento automatico e garantendo che le prestazioni del database rimangano ottimali nel nuovo ruolo. Questo passaggio proattivo consente di colmare il divario tra il mantenimento delle statistiche essenziali dell'optimizer e l'aggiornamento delle metriche delle attività per l'allineamento allo stato corrente del database.

Esperienza di riduzione della zona

Zonal: per eseguire il ripristino da un errore a livello di zona, è possibile eseguire il ripristino temporizzato usando il backup. È possibile scegliere un punto di ripristino personalizzato con l'ora più recente per ripristinare i dati più recenti. Un nuovo server flessibile viene distribuito in un'altra zona non impattata. Il tempo necessario per il ripristino dipende dal backup precedente e dal volume dei log delle transazioni da ripristinare.

Per altre informazioni sul ripristino temporizzato, vedere Backup e ripristino in Database di Azure per PostgreSQL - Server flessibile.

Con ridondanza della zona: viene eseguito automaticamente il failover del server flessibile nel server di standby entro 60-120 secondi senza perdita di dati.

Configurazioni senza zone di disponibilità

Anche se non è consigliabile, è possibile configurare il server flessibile senza disponibilità elevata abilitata. Per i server flessibili configurati senza disponibilità elevata, il servizio fornisce un'archiviazione con ridondanza locale con tre copie dei dati, un backup con ridondanza della zona (nelle aree in cui è supportato) e una resilienza integrata del server per riavviare automaticamente un server che si blocca e spostarlo in un altro nodo fisico. Questa configurazione offre un SLA di uptime del 99,9%. Durante gli eventi di failover pianificati o non pianificati, se il server diventa inattivo, il servizio mantiene la disponibilità dei server usando la procedura automatizzata seguente:

1. Viene eseguito il provisioning di una nuova VM Linux di calcolo.
2. Viene eseguito il mapping dell'archiviazione con i file di dati alla nuova macchina virtuale.
3. Il motore di database PostgreSQL viene portato online nella nuova macchina virtuale.

L'immagine seguente illustra la transizione tra una macchina virtuale e un errore di archiviazione.

Ripristino di emergenza e continuità aziendale tra aree

Se si verifica un disastro a livello regionale, Azure può fornire protezione dai disastri geografici regionali o su larga scala con il ripristino di emergenza utilizzando un'altra regione. Per altre informazioni sull'architettura del ripristino di emergenza di Azure, vedere Architettura del ripristino di emergenza da Azure ad Azure.

Il server flessibile offre funzionalità che proteggono i dati e attenuano i tempi di inattività per i database cruciali durante gli eventi di inattività pianificati e non pianificati. Basato sull'infrastruttura di Azure che offre resilienza e disponibilità solide, il server flessibile offre funzionalità di continuità aziendale che garantiscono protezione dagli errori, gestione dei requisiti di tempo di ripristino e riduzione dell'esposizione alla perdita di dati. Durante la progettazione delle applicazioni, prendere in considerazione la tolleranza al tempo di inattività, ovvero l'obiettivo del tempo di ripristino (RTO) e l'esposizione alla perdita di dati, ovvero l'obiettivo del punto di ripristino (RPO). Ad esempio, il database business critical richiede tempi di attività più rigorosi rispetto a un database di test.

Ripristino di emergenza nella geografia in più aree

Backup e ripristino con ridondanza geografica

Il backup e il ripristino con ridondanza geografica consentono di ripristinare il server in un'area diversa in caso di emergenza. Inoltre, in questo modo si ottiene almeno il 99,99999999999999% (16 nove) di durabilità degli oggetti di backup nell'arco di un anno specifico.

È possibile configurare il backup con ridondanza geografica solo quando si crea il server. Quando si configura il server con backup con ridondanza geografica, i dati di backup e i log delle transazioni vengono copiati nell'area abbinata in modo asincrono tramite la replica di archiviazione.

Per altre informazioni sul backup e il ripristino con ridondanza geografica, vedere Backup e ripristino con ridondanza geografica.

Repliche in lettura

È possibile distribuire repliche in lettura tra aree per proteggere i database da errori a livello di area. Le repliche in lettura vengono aggiornate in modo asincrono utilizzando la tecnologia di replica fisica di PostgreSQL e possono avere un ritardo rispetto al database primario. Le repliche in lettura sono supportate nei livelli di calcolo per utilizzo generico e ottimizzati per la memoria.

Per altre informazioni sulle funzionalità di replica in lettura e sulle considerazioni, vedere Repliche in lettura.

Rilevamento, notifica e gestione di interruzioni

Se si configura il server con il backup con ridondanza geografica, è possibile eseguire il ripristino geografico nell'area abbinata. Vengono eseguiti il provisioning e il ripristino di un nuovo server agli ultimi dati disponibili copiati in questa area.

È anche possibile usare repliche in lettura tra aree. In caso di errore dell'area, è possibile eseguire un'operazione di ripristino di emergenza promuovendo la replica in lettura come server scrivibile in lettura autonomo. È previsto che l'RPO arrivi a 5 minuti (possibile perdita di dati) tranne nel caso di un errore a livello di area grave, dove l'RPO può essere vicino al ritardo della replica al momento dell'errore.

Per altre informazioni sulla mitigazione e il ripristino dei tempi di inattività non pianificati dopo un'emergenza a livello di area, vedere Mitigazione dei tempi di inattività non pianificati.

Contenuti correlati

• Documentazione del Database di Azure per PostgreSQL
• Affidabilità in Azure