Replica geografica nel server flessibile di Database di Azure per PostgreSQL

È possibile creare una replica in lettura nella stessa area del server primario o in un'area geografica diversa. La replica geografica è utile per scenari come la pianificazione del ripristino di emergenza o l'avvicinamento dei dati agli utenti.

È possibile avere un server primario in qualsiasi area del servizio server flessibile di Database di Azure per PostgreSQL. Un server primario può anche avere repliche in qualsiasi area geografica globale di Azure che supporti Database di Azure per PostgreSQL - Server flessibile. Inoltre, il servizio supporta aree geografiche nei cloud sovrani Azure per enti pubblici e Microsoft Azure gestito da 21Vianet.

Aree abbinate a scopo di ripristino di emergenza

È possibile creare repliche in qualsiasi area supportata, ma si ottengono notevoli vantaggi quando si scelgono repliche in aree Azure abbinate, soprattutto 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. Questa priorità garantisce che le applicazioni tra aree abbinate abbiano sempre un'area accelerata per il ripristino.

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

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

  • Prestazioni: mentre le aree abbinate offrono in genere bassa latenza di rete, che migliora l'accessibilità dei dati e l'esperienza utente, potrebbero non essere sempre le aree con la latenza assoluta più bassa. Se l'obiettivo principale consiste nel gestire i dati più vicini agli utenti anziché classificare in ordine di priorità il ripristino di emergenza, 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.

Preparati ai disastri regionali

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 il server flessibile Database di Azure per PostgreSQL, prendere in considerazione questi passaggi chiave e considerazioni:

  1. Configurare una replica di lettura con replica geografica: configurare una replica di lettura in una regione separata dall'istanza primaria. Questa configurazione garantisce la continuità nel caso in cui l'area primaria subisca un'interruzione.
  2. Verificare la simmetria del server: l'azione più consigliata per la gestione delle interruzioni a livello di area è la promozione al server primario, ma viene fornita con un requisito di simmetria del server . Questo requisito indica 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 originario riprende automaticamente a funzionare, ma in un nuovo ruolo di replica.
  3. Configurare 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. Assicurati di impostare correttamente tutte le configurazioni e le funzionalità necessarie (ad esempio PgBouncer) sulla replica di lettura. Per altre informazioni, vedere la sezione Gestione della configurazione.
  5. Preparare l'alta disponibilità (HA): se la configurazione richiede l'alta disponibilità, questa non viene abilitata automaticamente su una replica promossa. Sarà necessario attivarla dopo la promozione. 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. 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 si verifica un'interruzione prolungata con un server flessibile Database di Azure per PostgreSQL in un'area specifica che minaccia il contratto di servizio dell'applicazione, tenere presente che entrambe le azioni descritte nella sezione seguente non sono guidate dal servizio. Entrambe le azioni richiedono l'intervento dell'utente. 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. Valutare le opzioni seguenti:

Alzare di livello al server primario

Questa opzione non richiede l'aggiornamento delle stringhe di connessione nell'applicazione, a condizione di configurare gli endpoint virtuali. Una volta attivato, l'endpoint di scrittura viene reindirizzato al nuovo primario in un'altra area e la colonna stato di replica nel portale di Azure mostra "Riconfigurazione in corso". Una volta ripristinata l'area interessata, il server primario precedente riprende automaticamente, ma ora in un ruolo di replica.

Alzare di livello a un server indipendente e rimuovere dalla replica

In alcuni casi, questa opzione potrebbe essere l'unica opzione praticabile. Dopo aver alzato di livello il server, 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 in lettura.

Contenuti correlati

  • Last updated on