Condividi tramite

Replica geografica in Database di Azure per PostgreSQL - Server flessibile

  • Articolo

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

È possibile creare una replica in lettura nella stessa area del server primario o in un’area geografica diversa. La replica geografica può essere utile per scenari come la pianificazione del ripristino di emergenza o per avvicinare i dati agli utenti.

È possibile avere un server primario in qualsiasi area di Database di Azure per PostgreSQL - Server flessibile. Un server primario può avere repliche anche in qualsiasi area globale di Azure che supporta il server flessibile Database di Azure per PostgreSQL. Sono supportate anche aree speciali Azure per enti pubblici e Microsoft Azure gestito da 21Vianet.

Aree abbinate a scopo di ripristino di emergenza

Durante la creazione di repliche in qualsiasi area supportata, è possibile scegliere repliche in aree abbinate ci sono diversi vantaggi, in particolare quando si progetta per scopi di ripristino di emergenza:

  • Sequenza di ripristino dell'area: in un'interruzione a livello di area geografica, il ripristino di un'area da ogni set associato è prioritario, assicurando così che le applicazioni tra aree abbinate abbiano sempre un'area accelerata per il ripristino.

  • Aggiornamento sequenziale: gli aggiornamenti delle aree abbinate vengono effettuati in ordine cronologico, riducendo al minimo il rischio di tempi di inattività derivanti da problemi correlati all'aggiornamento.

  • Isolamento fisico: viene mantenuta una distanza minima di circa 480 chilometri tra i data center in aree abbinate, riducendo il rischio di interruzioni simultanee dovute a eventi significativi.

  • Residenza dei dati: con alcune eccezioni, le aree in un set associato si trovano all'interno della stessa area geografica, soddisfacendo così i requisiti di residenza dei dati.

  • Prestazioni: mentre le aree abbinate offrono in genere bassa latenza di rete, migliorando l'accessibilità dei dati e l'esperienza utente, potrebbero non essere sempre le aree con la latenza più bassa assoluta. Se l'obiettivo principale consiste nel gestire i dati più vicini agli utenti anziché classificare in ordine di priorità il ripristino di emergenza, è fondamentale valutare tutte le aree disponibili per la latenza. In alcuni casi, un'area non abbinata potrebbe presentare la latenza più bassa. Per una comprensione completa, è possibile fare riferimento alle Cifre di latenza andata e ritorno di Azure per fare una scelta informata.

Per una conoscenza più approfondita dei vantaggi delle aree abbinate, vedere la documentazione di Azure sulla replica tra aree.

Errori e ripristino a livello di area

Le strutture di Azure in varie aree sono progettate per essere altamente affidabili. Tuttavia, in rari casi, un'intera area può diventare inaccessibile a causa di motivi che vanno da errori di rete a gravi scenari come calamità naturali. Le funzionalità di Azure consentono di creare applicazioni distribuite in più aree, assicurandosi che un errore in un'area non influisca su altri utenti.

Preparare le emergenze a livello di area

La preparazione per potenziali emergenze a livello di area è fondamentale per garantire il funzionamento ininterrotto delle applicazioni e dei servizi. Se si sta valutando un piano di emergenza affidabile per l'istanza del server flessibile di Database di Azure per PostgreSQL, ecco i passaggi e le considerazioni principali:

  1. Stabilire una replica in lettura con replica geografica: è essenziale configurare una replica di lettura in un'area separata dalla replica primaria. Ciò garantisce la continuità nel caso in cui l'area primaria subisca un'interruzione.
  2. Verificare la simmetria del server: l'azione "alza di livello a server primario" è la soluzione più consigliata per la gestione delle interruzioni a livello di area, ma viene fornita con un requisito di simmetria del server. Ciò significa che i server primario e di replica devono avere configurazioni identiche di impostazioni specifiche. I vantaggi dell'uso di questa azione includono:
    • Non è necessario modificare le stringhe di connessione dell'applicazione se si usano endpoint virtuali.
    • Fornisce un processo di ripristino facile in cui, una volta che l'area interessata è di nuovo online, il server primario originale riprende automaticamente la funzione, ma in un nuovo ruolo di replica.
  3. Configurare gli endpoint virtuali: gli endpoint virtuali consentono una transizione uniforme dell'applicazione a un'altra area in caso di interruzione. Eliminano la necessità di apportare modifiche alle stringhe di connessione dell'applicazione.
  4. Configurare la replica in lettura: non tutte le impostazioni del server primario vengono replicate nella replica di lettura. È fondamentale assicurarsi che tutte le configurazioni e le funzionalità necessarie (ad esempio PgBouncer) siano configurate in modo appropriato nella replica di lettura. Per altre informazioni, vedere la sezione Gestione della configurazione.
  5. Prepararsi per la disponibilità elevata (HA): se la configurazione richiede disponibilità elevata, non verrà abilitata automaticamente in una replica alzata di livello. Sarà necessario attivarla dopo l'innalzamento di livello. Prendere in considerazione l'automazione di questo passaggio per ridurre al minimo i tempi di inattività.
  6. Test regolari: simulare regolarmente scenari di emergenza a livello di area per convalidare soglie, destinazioni e configurazioni esistenti. Assicurarsi che l'applicazione risponda come previsto durante questi scenari di test.
  7. Seguire le linee guida generali di Azure: Azure fornisce indicazioni complete sull'affidabilità e la preparazione alle emergenze. È estremamente utile consultare queste risorse e integrare le procedure consigliate nel piano di preparazione.

Essere proattivi e prepararsi in anticipo per le emergenze a livello di area garantisce la resilienza e l'affidabilità delle applicazioni e dei dati.

Quando le interruzioni influiscono sul contratto di servizio

Se un'interruzione prolungata con Database di Azure per PostgreSQL server flessibile in un'area specifica che minaccia il contratto di servizio dell'applicazione, tenere presente che entrambe le azioni descritte di seguito non sono guidate dal servizio. L'intervento dell'utente è necessario per entrambe le azioni. È consigliabile automatizzare l'intero processo il più possibile e disporre di un monitoraggio affidabile. Per altre informazioni sulle informazioni fornite durante un'interruzione, vedere la pagina Interruzione del servizio. È possibile solo un innalzamento di livello Forzato in uno scenario di riduzione dell'area, il che significa che la quantità di dati persi è approssimativamente uguale al ritardo corrente tra la replica e il server primario. Di conseguenza, è fondamentale monitorare il ritardo. Tenere in considerazione la procedura seguente:

Alzare di livello al server primario

Questa opzione non richiederà l'aggiornamento delle stringhe di connessione nell'applicazione, a condizione che gli endpoint virtuali siano configurati. Dopo l'attivazione, l'endpoint del Writer riporterà il nuovo database primario in un'area diversa e la colonna Stato di replica nel portale di Azure visualizzerà "Riconfigurazione". Una volta ripristinata l'area interessata, il server primario precedente riprenderà automaticamente, stavolta con un ruolo di replica.

Alzare di livello a un server indipendente e rimuovere dalla replica

In tal caso, questa è l'unica opzione praticabile. Dopo aver alzato di livello il server, sarà necessario aggiornare le stringhe di connessione dell'applicazione. Una volta ripristinata l'area originale, il server primario precedente potrebbe diventare nuovamente attivo. Assicurarsi di rimuoverlo per evitare di incorrere in costi non necessari. Se si vuole mantenere la topologia precedente, ricreare la replica di lettura.

Contenuto correlato