Affidabilità in Database di Azure per PostgreSQL

Database di Azure per PostgreSQL è un servizio di database completamente gestito progettato per offrire un controllo granulare e flessibilità sulle funzioni di gestione del database e sulle impostazioni di configurazione. Il servizio offre funzionalità di disponibilità elevata e ripristino di emergenza in base alle esigenze.

Quando si usa Azure, l'affidabilità è una responsabilità condivisa. Microsoft offre una gamma di funzionalità per supportare la resilienza e il ripristino. L'utente è responsabile della comprensione del funzionamento di tali funzionalità all'interno di tutti i servizi usati e della selezione delle funzionalità necessarie per soddisfare gli obiettivi aziendali e gli obiettivi di tempo di attività.

Questo articolo descrive come rendere resiliente Database di Azure per PostgreSQL a un'ampia gamma di potenziali interruzioni e problemi, tra cui errori temporanei, interruzioni della zona di disponibilità, interruzioni dell'area e manutenzione del servizio. Descrive anche come usare i backup per eseguire il ripristino da altri tipi di problemi ed evidenzia alcune informazioni chiave sul contratto di servizio di Database di Azure per PostgreSQL.

Raccomandazioni per la distribuzione di produzione

Per informazioni su come distribuire Database di Azure per PostgreSQL per supportare i requisiti di affidabilità della soluzione e su come l'affidabilità influisce su altri aspetti dell'architettura, vedere Procedure consigliate per l'architettura per Database di Azure per PostgreSQL in Azure Well-Architected Framework.

Panoramica dell'architettura di affidabilità

Questa sezione descrive alcuni degli aspetti importanti del funzionamento del servizio più rilevanti dal punto di vista dell'affidabilità. La sezione presenta l'architettura logica, che include alcune delle risorse e delle funzionalità distribuite e usate. Illustra anche l'architettura fisica, che fornisce informazioni dettagliate sul funzionamento del servizio sotto le quinte.

Architettura logica

Quando si lavora con Database di Azure per PostgreSQL, si distribuisce un server, che rappresenta le risorse di calcolo e di archiviazione necessarie per supportare il server di database. Distribuisci uno o più database sul server.

I server possono essere distribuiti in più livelli di calcolo: burstable, per utilizzo generico e ottimizzato per la memoria, ognuno dei quali è ottimizzato per diversi tipi di carichi di lavoro. In alcune aree di Azure è possibile distribuire server con Confidential Computing di Azure.

Per altre informazioni sull'architettura del servizio generale e sui modelli di distribuzione, vedere Informazioni su Database di Azure per PostgreSQL.

Architettura fisica

• Separazione di calcolo e archiviazione: Database di Azure per PostgreSQL usa un'architettura di separazione delle risorse di calcolo e archiviazione per supportare la disponibilità elevata. Il motore di database viene eseguito in una macchina virtuale Linux, mentre i file di dati vengono archiviati in Archiviazione di Azure, che gestisce tre copie sincrone con ridondanza locale dei file di database per garantire la durabilità dei dati.

• Disponibilità elevata: Facoltativamente, è possibile abilitare una configurazione a disponibilità elevata nel server. Quando si abilita la configurazione a disponibilità elevata, il servizio effettua il provisioning e gestisce un server warm standby. Le modifiche ai dati nel server primario vengono replicate in modo sincrono nel server di standby per garantire una perdita di dati pari a zero durante un errore del server primario.

  L'architettura separa il livello di calcolo dal livello di archiviazione, consentendo al servizio di gestire in modo appropriato diversi tipi di errori. Per una maggiore resilienza, è possibile distribuire i server tra zone di disponibilità.

  

  Un server standby viene distribuito nella stessa configurazione della macchina virtuale del server primario, inclusi vCore, archiviazione e impostazioni di rete.

  È possibile passare da un server all'altro eseguendo un failover. Esistono due tipi di failover: failover forzati, che vengono usati quando il server primario ha esito negativo e failover pianificati, che vengono usati durante alcune operazioni di manutenzione e in altri scenari in cui è necessario ridurre al minimo i tempi di inattività dell'applicazione durante un failover.

  Operazioni come l'arresto, l'avvio e il riavvio vengono eseguite contemporaneamente sui server di database primari e di standby. 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.

  Per altre informazioni, vedere Disponibilità elevata in Database di Azure per PostgreSQL.

• Backup: Database di Azure per PostgreSQL crea automaticamente i backup del server. Per altre informazioni, vedere Backup e ripristino.

Resilienza a errori temporanei

Gli errori temporanei sono errori brevi e intermittenti nei componenti. Si verificano spesso in un ambiente distribuito come il cloud e fanno parte delle normali operazioni. Gli errori temporanei si correggono dopo un breve periodo di tempo. È importante che le applicazioni possano gestire gli errori temporanei, in genere ritentando le richieste interessate.

Tutte le applicazioni ospitate nel cloud devono seguire le indicazioni sulla gestione degli errori temporanei di Azure quando comunicano con qualsiasi API, database e altri componenti ospitati nel cloud. Per altre informazioni, vedere Raccomandazioni per la gestione degli errori temporanei.

Le applicazioni devono gestire errori di connettività temporanei che possono verificarsi durante la manutenzione, il ridimensionamento delle operazioni o le interruzioni di rete. Seguire queste raccomandazioni:

• Quando l'applicazione rileva errori temporanei, ripetere l'operazione usando il backoff esponenziale. Aumentare il ritardo tra i tentativi e limitare il numero di tentativi. Se l'operazione ha ancora esito negativo dopo i tentativi massimi, considerarla come un errore.
• Se possibile, utilizzare librerie client (denominate anche driver) che gestiscono automaticamente i tentativi.
• Gli errori temporanei che si verificano durante le operazioni di scrittura richiedono una considerazione più attenta. Valutare la possibilità di rendere idempotenti le operazioni di scrittura, in modo che possano essere eseguite più volte in modo sicuro.

Per altre informazioni, vedere Gestione degli errori di connettività temporanei in Database di Azure per PostgreSQL.

Resilienza ai guasti delle zone di disponibilità

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

È possibile selezionare il tipo di supporto della zona di disponibilità tramite la configurazione a disponibilità elevata. L'abilitazione della disponibilità elevata distribuisce un server standby insieme al server primario. Questo modello di disponibilità elevata consente di garantire che i dati di cui è stato eseguito il commit non vengano mai persi durante gli errori. Indipendentemente dal modello di distribuzione a disponibilità elevata usato dal server, i dati vengono sottoposti a commit sincrono sia nei server primario che in quello di standby. Se si verifica un'interruzione nel server primario, il server esegue automaticamente il failover nel server di standby.

I file di dati e i log write-ahead (WALs) vengono archiviati in dischi gestiti Premium all'interno di ogni zona di disponibilità, con archiviazione con ridondanza locale (LRS) che archivia automaticamente tre copie di dati all'interno di ogni zona.

Database di Azure per PostgreSQL supporta due tipi di configurazione della zona di disponibilità quando si usa la disponibilità elevata:

• Disponibilità elevata con ridondanza della zona: La ridondanza della zona offre il massimo livello di resilienza della zona distribuendo un server primario in una zona di disponibilità e un server standby in una zona di disponibilità diversa. Il server standby usa una configurazione di calcolo, archiviazione e rete simile a quella primaria. Una configurazione con ridondanza della zona fornisce l'isolamento fisico dell'intero stack tra i server primari e di standby.

  È possibile selezionare le zone di disponibilità per i server primario e standby oppure consentire a Microsoft di sceglierle.

  È consigliabile usare distribuzioni con ridondanza della zona per i server di produzione.

  

  Le operazioni di scrittura possono riscontrare un piccolo aumento della latenza di commit perché il servizio replica in modo sincrono i dati nel server di standby. L'impatto varia in base al carico di lavoro, allo SKU selezionato e all'area.

• Alta disponibilità zonale (stessa zona): I server primario e standby utilizzano la stessa zona di disponibilità. Se si verifica un'interruzione del server primario, ma la zona è ancora integra, il server esegue automaticamente il failover nel server di standby. Una distribuzione a livello di zona offre disponibilità elevata all'interno di una singola zona di disponibilità. Protegge l'utente da errori a livello di nodo e consente anche di ridurre i tempi di inattività dell'applicazione durante gli eventi di tempo di inattività pianificati e non pianificati. Tuttavia, non protegge da un'interruzione in tale zona.

  

  L'alta disponibilità nella stessa zona è applicabile solo nelle situazioni seguenti:

  • La regione non supporta le zone di disponibilità. L'area funziona in modo efficace come una singola zona, quindi l'unica configurazione a disponibilità elevata che puoi selezionare è quella a zona unica.
  • Se un'area non dispone di capacità sufficiente per una distribuzione con ridondanza della zona, il servizio può inizialmente posizionare entrambi i server nella stessa zona di disponibilità ed eseguirne automaticamente la migrazione in zone separate quando la capacità diventa disponibile. Questa opzione è disponibile quando si usa il portale di Azure o l'interfaccia della riga di comando di Azure per distribuire un server. Per altre informazioni, vedere Configurare le opzioni business critical (disponibilità elevata).

  Poiché i server si trovano nella stessa zona, può ridurre la latenza di scrittura nelle applicazioni distribuite all'interno della stessa zona.

Se si configura il server senza disponibilità elevata, viene eseguito in un singolo server. Se il server o la relativa zona diventa inattivo, il server non è disponibile. Per altre informazioni, vedere Configurazioni senza zone di disponibilità.

Requisiti

• Supporto per l'area: Il supporto di Database di Azure per PostgreSQL per le configurazioni della zona di disponibilità differisce tra le aree di Azure. Per un elenco completo delle aree e dei tipi di supporto della zona di disponibilità e per eventuali considerazioni specifiche per tale area, vedere Aree di Azure.

• Livello di calcolo: La tabella seguente elenca il supporto del livello di calcolo per ogni tipo di supporto della zona di disponibilità:

  Piano tariffario	Zone-redundant	Zonale (nella stessa zona)
  Possibilità di burst	Non supportato	Supportato
  General Purpose	Supportato	Supportato
  Memoria Ottimizzata	Supportato	Supportato

• Livello di servizio: La ridondanza della zona richiede livelli per utilizzo generico o ottimizzato per la memoria.

  Le distribuzioni di zona (stessa zona) sono supportate in tutti i piani tariffari.

Considerazioni

Capacità dell'area: Se un'area non dispone di capacità sufficiente per una distribuzione con ridondanza della zona, il servizio può inizialmente posizionare entrambi i server nella stessa zona di disponibilità ed eseguirne automaticamente la migrazione in zone separate quando la capacità diventa disponibile. Questa opzione è disponibile quando si usa il portale di Azure o l'interfaccia della riga di comando di Azure per distribuire un server. Per altre informazioni, vedere Configurare le opzioni business critical (disponibilità elevata).

Cost

Quando si abilita la disponibilità elevata, il server di standby viene creato e fatturato con la stessa tariffa del server primario. La configurazione della zona di disponibilità non influisce sul costo. Non sono previsti addebiti per la replica dei dati all'interno o tra le zone di disponibilità. A seconda del volume di memoria di backup, potrebbe esserti addebitata anche la memoria di backup. Per informazioni dettagliate sui prezzi, vedere Prezzi di Database di Azure per PostgreSQL.

Configurare il supporto delle zone di disponibilità

Per configurare il supporto della zona di disponibilità per un server, configurare le impostazioni di disponibilità elevata.

• Creare un server con ridondanza della zona: Per informazioni su come creare un server con disponibilità elevata e ridondanza della zona abilitata, vedere Avvio rapido: Creare un database di Azure per PostgreSQL nel portale di Azure.

• Modificare la configurazione della zona di disponibilità per i server esistenti: È possibile modificare la configurazione della zona di disponibilità per i server esistenti modificando le impostazioni di disponibilità elevata. Per i passaggi dettagliati, vedere Abilitare la disponibilità elevata per i server esistenti.

  Non è possibile modificare la zona usata per il server primario o standby dopo la creazione. È necessario ricreare il server.

  Suggerimento

  È consigliabile attendere che l'attività del server non sia bassa prima di modificare la configurazione a disponibilità elevata.

• Disabilitare la disponibilità elevata: La disabilitazione della disponibilità elevata rimuove il server di standby, quindi il server non è resiliente alle interruzioni nella zona di disponibilità. Per altre informazioni, vedere Disabilitare la disponibilità elevata.

Comportamento quando tutte le zone sono integre

Questa sezione descrive cosa aspettarsi quando i server sono configurati con supporto per l'alta disponibilità e il supporto per le zone di disponibilità e tutte le zone di disponibilità sono operative.

• Operazione tra zone: Le applicazioni client PostgreSQL si connettono al server primario usando il nome del server di database. Database di Azure per PostgreSQL usa una configurazione attiva/passiva in cui tutte le connessioni e le query del database vengono gestite dal server primario nella zona di disponibilità primaria. Il server standby non gestisce il traffico client durante le normali operazioni.

• Replica dei dati tra zone: Le modifiche ai dati vengono replicate in modo sincrono tra i server primari e di standby. Le transazioni non vengono considerate complete fino a quando i server primario e standby non confermano la scrittura.

  La scrittura e il commit delle transazioni attivate dall'applicazione vengono registrati prima nel WAL sul 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 processo di riconoscimento non attende che i log vengano applicati al server di standby.

  Gli effetti della replica sono diversi a seconda della configurazione della zona di disponibilità usata dal server:

  • Ridondanza della zona: Poiché i server si trovano in zone separate, questo approccio garantisce una perdita di dati pari a zero durante un errore di zona. Questa situazione viene talvolta chiamata anche raggiungimento di un obiettivo del punto di ripristino (RPO) pari a zero per gli errori di zona.

    Tuttavia, la replica tra zone potrebbe introdurre una piccola quantità di latenza aggiuntiva. L'impatto della latenza dipende dall'applicazione e per la maggior parte delle applicazioni è trascurabile.

  • Zona: poiché entrambi i server si trovano nella stessa zona, non viene replicato alcun traffico tra zone.

  Annotazioni

  Il sistema replica i dati di log in tempo reale nel server di standby. Eventuali errori utente nel server primario, ad esempio l'eliminazione accidentale di una tabella o gli aggiornamenti non corretti dei dati, vengono replicati nel server di standby. Non è quindi possibile usare lo standby per eseguire il ripristino da questi tipi di errori ed è necessario eseguire un ripristino temporizzato dal backup. Per altre informazioni, vedere Backup e ripristino.

Comportamento durante un errore di zona

Questa sezione descrive cosa aspettarsi quando i server sono configurati con supporto per l'alta disponibilità e per le zone di disponibilità e si verifica un'interruzione della zona di disponibilità.

• Rilevamento e risposta: Azure controlla periodicamente l'integrità dei server primario e standby. Dopo diversi ping, se il monitoraggio dell'integrità rileva che un server primario non è raggiungibile, il servizio avvia un failover automatico verso il server di standby. L'algoritmo di monitoraggio della salute utilizza più dati per evitare situazioni di falsi positivi.

  In caso di errore di zona, il comportamento è diverso a seconda della configurazione della zona di disponibilità usata dal server:

  • Ridondanza della zona: Database di Azure per PostgreSQL rileva automaticamente gli errori della zona di disponibilità. Per visualizzare i possibili tipi di stato di disponibilità elevata, vedere Tipi di stato di disponibilità elevata. Quando una zona ha esito negativo, Azure avvia un failover forzato nel server di standby senza che sia necessario intervenire.

  • Zonale: Se la zona di disponibilità che ospita un server di zona non è più disponibile, i server primario e di standby non sono disponibili. In questo scenario, il servizio non fornisce il failover automatico. Sei responsabile del rilevamento dell'interruzione della zona e dell'esecuzione di azioni di ripristino, ad esempio il ripristino di backup a ridondanza di zona in un server separato in un'altra zona o regione di disponibilità.

• Notifica: Il monitoraggio dello stato di integrità a disponibilità elevata in Database di Azure per PostgreSQL offre una panoramica continua dell'integrità e dell'idoneità delle istanze abilitate per la disponibilità elevata. La funzionalità di monitoraggio è basata su Integrità delle risorse di Azure e può rilevare e avvisare eventuali problemi che potrebbero influire sulla prontezza al failover del database o sulla disponibilità complessiva. Valutare le metriche chiave, ad esempio lo stato della connessione, lo stato di failover e l'integrità della replica dei dati, per abilitare la risoluzione dei problemi proattivi e mantenere il tempo di attività e le prestazioni 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.

• Richieste attive: Quando una zona di disponibilità non è più disponibile, le richieste in corso ai server nella zona interessata potrebbero essere terminate. Le applicazioni devono ritentare queste richieste. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

• Perdita di dati prevista: La quantità di perdita di dati dipende dalla configurazione della zona di disponibilità usata dal server.

  • Zone-redundant: Nessuna perdita di dati è prevista durante il failover della zona grazie alla replica sincrona tra il server primario e quello di standby in zone diverse.

  • Zonale: I dati nei server nella zona interessata non sono disponibili fino al ripristino della zona.

• Tempo di inattività previsto: La quantità di tempo di inattività dipende dalla configurazione della zona di disponibilità usata dal server.

  • Ridondanza della zona: Il failover viene in genere completato entro 60-120 secondi. Se i clienti gestiscono in modo appropriato gli errori temporanei con tentativi dopo un breve periodo di tempo, in genere evitano un impatto significativo.

  • Zonale: I server in una zona interessata non sono disponibili fino al ripristino della zona di disponibilità.

• Ridistribuzione: Il comportamento di reindirizzamento del traffico dipende dalla configurazione della zona di disponibilità usata dal server.

  • Ridondanza della zona: Dopo il failover, il server di standby precedente diventa il nuovo server primario e inizia ad accettare nuove connessioni. Azure stabilisce automaticamente un nuovo server standby nella zona primaria originale dopo il ripristino. Per informazioni dettagliate, vedere Failover forzato.

  • Zonale: Quando una zona non è disponibile, il server non è disponibile. Se si dispone di un server separato creato in un'altra zona o area di disponibilità, si è responsabili del reindirizzamento del traffico a tale server.

Ripristino della zona

Il comportamento di ripristino della zona dipende dalla configurazione della zona di disponibilità usata dal server.

• Zone-redondante: Quando la zona di disponibilità viene ripristinata, Azure Database per PostgreSQL ricostruisce automaticamente il server di standby nella zona ripristinata e lo sincronizza con il server primario corrente. La zona ripristinata funge quindi da posizione di standby. Il servizio non sposta automaticamente il ruolo primario nella zona originale per evitare interruzioni non necessarie. È possibile avviare manualmente un failover pianificato se si desidera restituire il database primario alla zona originale.

• Zonale: Dopo che la zona è salubre, i server nella zona sono nuovamente disponibili. L'utente è responsabile delle procedure di ripristino della zona e della sincronizzazione dei dati richiesta dai carichi di lavoro.

Verifica dei guasti di zona

Le opzioni per il test per gli errori di zona dipendono dalla configurazione della zona di disponibilità usata dall'istanza.

• Zone ridondante: Puoi testare la resilienza dell'applicazione in caso di failover avviando un failover forzato. Un failover forzato consente di simulare uno scenario di interruzione non pianificato durante l'esecuzione del carico di lavoro e osservare il tempo di inattività dell'applicazione. È consigliabile eseguire simulazioni in un ambiente non di produzione o in un momento non di produzione. Per altre informazioni, vedere Avviare un failover forzato.

• Zonale: Anche se non è possibile simulare un'interruzione completa della zona, è possibile simulare che il tuo server non sia disponibile in modo analogo a quello che accade durante un'interruzione della zona. Per altre informazioni, vedere Arrestare il calcolo di un server.

Resilienza agli errori a livello di area

Database di Azure per PostgreSQL supporta repliche in lettura tra aree, che è possibile usare per mantenere una copia sincronizzata del database in un'area diversa per un ripristino più rapido.

È anche possibile usare i backup con ridondanza geografica, nelle aree supportate, per fornire il ripristino tra aree. Tuttavia, i backup comportano in genere tempi di inattività e perdita di dati maggiori rispetto alla replica. Per altre informazioni, vedere Backup e ripristino.

Repliche di lettura tra regioni

È possibile distribuire repliche in lettura per proteggere i database da errori a livello di area. Ogni replica in lettura è un server di Database di Azure per PostgreSQL separato. Quando si inserisce una replica di lettura in una seconda regione di Azure, il server di database può fornire resilienza a un problema a livello di regione. È possibile distribuire fino a cinque repliche in lettura, che facoltativamente possono trovarsi in aree di Azure diverse. La tecnologia di replica fisica di PostgreSQL aggiorna le repliche in lettura in modo asincrono e queste possono essere in ritardo rispetto al database primario. Le repliche di lettura tra regioni possono opzionalmente servire carichi di lavoro di sola lettura per ridurre la latenza per le applicazioni distribuite a livello globale o per ridurre il traffico di lettura dal server primario. Per altre informazioni sulle funzionalità di replica in lettura e sulle considerazioni, vedere Repliche in lettura.

Gli endpoint virtuali forniscono endpoint di lettura-scrittura e di sola lettura e reindirizzano automaticamente il traffico quando una replica viene promossa, riducendo al minimo i tempi di inattività durante gli eventi di failover. Consigliamo fortemente di utilizzare endpoint virtuali con repliche di lettura tra regioni per migliorare la resilienza delle applicazioni. Per altre informazioni, vedere Endpoint virtuali per le repliche in lettura in Database di Azure per PostgreSQL.

Se l'area primaria ha esito negativo, è possibile attivare una promozione in modo che la replica secondaria diventi la replica primaria. Esistono diversi tipi di failover che è possibile attivare a seconda del modo in cui si usano le repliche di lettura. Quando si usano repliche di lettura per fornire resilienza ai guasti della regione, in genere si usa l'approccio promuovere a server primario, che aggiorna l'endpoint virtuale. Durante un'interruzione dell'area, è necessario eseguire una promozione forzata, che può comportare una perdita di dati per i dati non replicati. Negli scenari pianificati in cui l'area primaria è integra, è possibile scegliere di eseguire una promozione pianificata per evitare la perdita di dati. Per ulteriori informazioni, vedere Promuovere le repliche di lettura nel database Azure per PostgreSQL.

Annotazioni

Questa sezione riepiloga alcune informazioni chiave su come le repliche di lettura possono supportare la resilienza ai guasti su scala regionale. È anche possibile usare repliche in lettura per migliorare le prestazioni e supportare basi utente geograficamente distribuite su grande scala. Per altre informazioni, vedere Leggere le repliche.

Requisiti

• Supporto per le regioni: È possibile creare repliche in lettura tra aree in qualsiasi regione che supporta Database di Azure per PostgreSQL. Non si è limitati alle aree abbinate di Azure.

• Livelli di calcolo: I livelli di calcolo ottimizzati per la memoria e per utilizzo generico supportano le repliche in lettura. Il livello burstable non supporta le repliche in lettura.

Considerazioni

• Differenze di configurazione: Le repliche in lettura potrebbero non ereditare tutte le impostazioni di configurazione dal server primario. Pianificare la configurazione delle impostazioni necessarie dopo il failover. Il server primario e le repliche devono essere simmetriche, il che significa che devono avere gli stessi livelli, dimensioni di archiviazione e valori per alcune impostazioni. Durante i guasti regionali, il requisito del server simmetrico può essere derogato per le promozioni forzate del server, ma è buona prassi avere una configurazione simmetrica, se possibile, per evitare problemi inattesi. Per altre informazioni, vedere Gestione della configurazione.

• Monitoraggio del ritardo della replica: Il processo di replica asincrona richiede un ritardo di replica, che può variare a seconda di diversi fattori. Quando il ritardo di replica è molto elevato, il server potrebbe riscontrare problemi. È importante monitorare il ritardo di replica per attenuare i problemi prima che si aggravino. Per altre informazioni, vedere Monitorare la replica.

• Disponibilità elevata: Le repliche di lettura non possono avere la disponibilità elevata abilitata e, quando vengono promosse, non hanno la disponibilità elevata. Sei responsabile della configurazione della disponibilità elevata dopo la promozione di una replica.

Per altre considerazioni che si applicano al processo di promozione, vedere Promozione delle repliche di lettura in Database di Azure per PostgreSQL - Considerazioni.

Cost

Le repliche in lettura comportano costi di calcolo e archiviazione, nonché addebiti per il trasferimento dei dati tra regioni per la replicazione. Per informazioni dettagliate sui prezzi, vedere Prezzi di Database di Azure per PostgreSQL e Prezzi della larghezza di banda.

Configurare il supporto per più aree

• Creare una replica di lettura: Per informazioni su come creare una replica di lettura, vedere Creare una replica di lettura. Le repliche possono essere configurate dopo la creazione del server primario, purché il server primario sia in esecuzione e accessibile.

  Per creare un endpoint virtuale, vedere Creare endpoint virtuali.

• Eliminare una replica di lettura: Per informazioni su come eliminare una replica in lettura, vedere Eliminare una replica di lettura.

Comportamento quando tutte le aree sono integre

Questa sezione descrive cosa aspettarsi quando il server è configurato con una replica in lettura in un'altra area e un endpoint virtuale e tutte le aree sono operative:

• Routing del traffico tra aree: Nelle normali operazioni, l'endpoint virtuale indirizza il traffico per l'endpoint di lettura/scrittura al server primario nell'area primaria. Se si utilizza anche l'endpoint di sola lettura dell'endpoint virtuale, il traffico viene indirizzato verso qualsiasi replica configurata.

• Replica dei dati tra aree: Le repliche in lettura tra aree usano la replica asincrona per ridurre al minimo l'impatto sulle prestazioni del server primario. La quantità di ritardo della replica dipende da diversi fattori, tra cui il carico di scrittura e la latenza tra il server primario e le repliche. Il ritardo della replica è in genere di almeno alcuni minuti, ma può essere molto più lungo. Per altre informazioni, vedere Monitorare la replica.

Comportamento durante un errore di area

Questa sezione descrive cosa aspettarsi quando il server è configurato con una replica in lettura in un'altra area e un endpoint virtuale ed è presente un'interruzione nell'area primaria:

• Rilevamento e risposta: Si è responsabili del rilevamento di un'interruzione nella regione primaria e della promozione manuale di una replica di lettura per diventare il nuovo server primario. Durante un'interruzione della regione, è necessario eseguire una promozione forzata, che comporta la perdita dei dati non replicati.

  Importante

  Sei responsabile dell'attivazione della promozione. Azure non promuove automaticamente le repliche in lettura, anche se si verifica un errore nell'area.

  Per i passaggi dettagliati per avviare una promozione, vedere Passare alla replica in lettura a primaria.

• Notifica: Microsoft non invia automaticamente una notifica quando un'area è inattiva. È tuttavia possibile usare Integrità dei servizi di Azure per comprendere l'integrità complessiva del servizio, inclusi gli eventuali errori dell'area e configurare gli avvisi di integrità dei servizi per notificare eventuali problemi.

• Richieste attive: Tutte le connessioni attive all'area primaria vengono eliminate. Le applicazioni devono riprovare a stabilire connessioni alla replica promossa dopo il completamento del processo di promozione.

• Perdita di dati prevista: Durante un'interruzione dell'area, è necessario eseguire una promozione forzata, che comporta la perdita permanente di tutti i dati non replicati.

  La quantità di perdita di dati dipende dal ritardo di replica al momento dell'interruzione. Il ritardo della replica è in genere di almeno alcuni minuti, ma può essere molto più lungo. Per altre informazioni, vedere Monitorare la replica.

• Tempo di inattività previsto: L'innalzamento forzato viene in genere completato entro 1-3 minuti dall'attivazione. Le applicazioni potrebbero anche dover riconnettersi all'endpoint corretto. Gli endpoint virtuali vengono aggiornati come parte del processo di promozione forzata. Le applicazioni devono rispettare la durata (TTL) dei record DNS dell'endpoint per garantire che si riconnettano rapidamente alla replica corretta al termine della promozione.

• Reindirizzamento del traffico: L'endpoint virtuale per il server reindirizza automaticamente il traffico dell'applicazione alla nuova replica primaria.

  Annotazioni

  Dopo che una replica di lettura viene promossa a server primario, la configurazione di alta disponibilità non è abilitata. È necessario abilitare manualmente la configurazione a disponibilità elevata o aggiungerla ai propri processi di automazione.

Ripristino della regione

Quando si usano gli endpoint virtuali, dopo il ripristino dell'area primaria, il server primario precedente viene configurato automaticamente come replica di lettura. È possibile eseguire un'altra promozione per restituire le operazioni primarie all'area primaria preferita.

Testare gli errori dell'area

Testare regolarmente le procedure di promozione delle repliche in lettura per assicurarsi che i processi siano validi e che le funzionalità soddisfino i requisiti RTO e RPO.

È possibile alzare di livello una replica di lettura per diventare il server primario in qualsiasi momento, anche quando tutte le aree sono integre. Per i test:

• È possibile eseguire test di promozione forzati. È consigliabile eseguire questi test in un ambiente non di produzione perché può comportare la perdita di dati. I test di promozione forzata consentono di simulare il comportamento che si verifica durante un guasto della regione.
• Per gli scenari di manutenzione pianificata o di test in cui si vuole evitare la perdita di dati, usare invece una promozione pianificata. Tenere presente che la promozione pianificata segue un processo diverso rispetto alla promozione durante un'interruzione di servizio regionale.

Per istruzioni dettagliate, vedere Convertire la replica di lettura in primaria.

Come parte della strategia di ripristino di disastro, eseguire regolarmente esercitazioni di recupero complete. Queste esercitazioni devono includere la convalida dei dati, i test delle funzionalità dell'applicazione e le procedure di rollback documentate.

Backup e ripristino

Database di Azure per PostgreSQL esegue automaticamente i backup che forniscono funzionalità di ripristino temporizzato e consentono di proteggersi da danneggiamenti ed eliminazioni accidentali dei dati. I backup sono completamente gestiti da Microsoft, non interrompono la disponibilità del server e includono sia backup completi che backup del log delle transazioni.

• Archiviazione di backup: Se il server è configurato con alta disponibilità e ridondanza di zona, i backup vengono archiviati nell'archiviazione con ridondanza di zona. Per i server configurati senza disponibilità elevata o con disponibilità elevata (zona singola), i backup vengono archiviati nell'archiviazione con ridondanza locale.

  Nelle aree di Azure con coppie è possibile configurare l'archiviazione di backup con ridondanza geografica (GRS) al momento della creazione del server per replicare i backup nell'area abbinata di Azure per una maggiore protezione dagli errori dell'area. I backup vengono replicati in modo asincrono.

  Il periodo di conservazione dei backup predefinito è di 7 giorni, con l'opzione per estendere la conservazione fino a 35 giorni. È anche possibile usare Backup di Azure per l'archiviazione a lungo termine di backup manuali per un massimo di 10 anni. Tutti i backup vengono crittografati.

• Ripristinare: Il ripristino temporizzato consente di ripristinare il database in qualsiasi momento entro il periodo di conservazione dei backup. Il processo di ripristino crea un nuovo server di database con un nuovo nome server fornito dall'utente, che è quindi possibile usare as-is o copiare i dati da.

  Quando si ripristina un backup con ridondanza geografica, si crea un nuovo server nell'area abbinata.

  Questa funzionalità è utile per il ripristino da modifiche accidentali ai dati, errori dell'applicazione o scenari di test.

Per la maggior parte delle soluzioni, non è consigliabile basarsi esclusivamente sui backup. Usare invece le altre funzionalità descritte in questa guida per supportare i requisiti di resilienza. Tuttavia, i backup proteggono da alcuni rischi che altri approcci non comportano. Per altre informazioni, vedere Che cosa sono ridondanza, replica e backup?.

Per altre informazioni, vedere Backup e ripristino in Database di Azure per PostgreSQL.

Resilienza alla manutenzione del servizio

Database di Azure per PostgreSQL gestisce automaticamente le attività di manutenzione critiche, tra cui l'applicazione di patch dell'hardware, del sistema operativo e del motore di database sottostanti. Il servizio include aggiornamenti della sicurezza, aggiornamenti software e aggiornamenti delle versioni secondarie come parte della manutenzione pianificata.

Per assicurarsi che il server rimanga disponibile durante le finestre di manutenzione, seguire queste indicazioni:

• Abilitare la disponibilità elevata: Durante la manutenzione, potrebbe essere necessario riavviare il server come parte del processo di aggiornamento. Se è abilitata la disponibilità elevata, le operazioni di manutenzione in genere usano gli aggiornamenti in sequenza per ridurre al minimo i tempi di inattività. Le attività di manutenzione periodiche, come gli aggiornamenti della versione minore, vengono eseguite prima nella replica di 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. Questa sequenza si applica sia che il server utilizzi un'alta disponibilità con ridondanza zonale, sia un'alta disponibilità zonale.

  Per i server senza alta disponibilità abilitata, aspettati brevi tempi di inattività durante le operazioni di manutenzione. Con l'alta disponibilità attivata, le operazioni di manutenzione vengono in genere completate con tempi di inattività minimi o nulli.

• Configurare finestre di manutenzione personalizzate: È possibile configurare la pianificazione della manutenzione in modo che sia gestita dal sistema o definire una finestra di manutenzione personalizzata per ridurre al minimo l'impatto sulle operazioni aziendali. Pianificare la manutenzione durante periodi di attività ridotta per ridurre al minimo l'impatto aziendale. Per altre informazioni, vedere Pianificare la manutenzione.

• Implementare la logica di ripetizione dei tentativi: Assicurarsi che le applicazioni possano gestire brevi interruzioni della connettività che possono verificarsi durante i riavvii di manutenzione. Per rendere resilienti le applicazioni a questi tipi di problemi, vedere Indicazioni sulla resilienza per gli errori temporanei .

Contratto di servizio

Il contratto di servizio per i servizi di Azure descrive la disponibilità prevista di ogni servizio e le condizioni che la soluzione deve soddisfare per raggiungere tale aspettativa di disponibilità. Per altre informazioni, vedere SLA per servizi online.

Database di Azure per PostgreSQL offre contratti di servizio di disponibilità diversi in base alla configurazione del server:

• Server configurati con alta disponibilità ridondante tra zone.
• Server configurati con disponibilità elevata di zona (zona singola).
• Server configurati senza disponibilità elevata.

Contenuti correlati

• L'affidabilità di Azure
• Procedure consigliate per l'architettura per Database di Azure per PostgreSQL
• Panoramica della continuità aziendale con Database di Azure per PostgreSQL
• Ripristino di emergenza geografico in Database di Azure per PostgreSQL
• Acceleratore di soluzioni di resilienza di Database di Azure per PostgreSQL : script Terraform per implementare molti dei principi di resilienza e recuperabilità descritti in questo articolo.