Proteggere i dati con la replica zonale e regionale

Seleziona una versione della documentazione:

Questa pagina descrive l'architettura di riferimento per l'alta disponibilità di AlloyDB Omni Premium, che include la protezione dei dati tramite la replica zonale in una regione (alta disponibilità) e aggiunge la protezione per il ripristino di emergenza (RE) utilizzando lo streaming asincrono su grandi confini geografici.

Questa architettura di riferimento è più adatta ai seguenti casi d'uso:

  • Per le applicazioni mission-critical, oltre alla protezione a livello di zona, è necessaria anche una protezione a livello di regione.

Questa architettura di riferimento per la disponibilità incorpora repliche di lettura all'interno della regione per l'alta affidabilità e in più regioni per il disaster recovery. Questo deployment multiregionale protegge da interruzioni significative, tra cui interruzioni di corrente diffuse e disastri naturali su larga scala.

Considerazioni sull'architettura di riferimento per la disponibilità

Quando valuti questa architettura di riferimento per la disponibilità, considera i seguenti fattori:

  • Latenza e larghezza di banda della rete all'interno della regione e tra le regioni
  • Posizionamento geografico di database e server delle applicazioni
  • Strategia per l'offload dei carichi di lavoro di sola lettura alle repliche
  • Esegui il deployment dell'alta disponibilità nella regione di RE remota

Il bilanciamento del carico di sola lettura potrebbe essere necessario, soprattutto se utilizzi server delle applicazioni regionali, in modo che le richieste vengano inoltrate al database più vicino per la risposta più rapida. Per ulteriori informazioni, consulta Routing delle richieste a un bilanciatore del carico delle applicazioni classico multiregionale.

Potrebbe essere necessario un monitoraggio aggiuntivo per la replica tra regioni per garantire che il ritardo di replica non inizi ad aumentare a causa del carico delle transazioni o della capacità di rete.

Per assicurarti che il RE vada a buon fine, esegui test approfonditi. È importante testare la funzionalità e il throughput dell'applicazione se esistono connessioni di rete a latenza elevata tra i server delle applicazioni e il database.

Architetture di alta affidabilità nella regione e di RE tra regioni

La Figura 1 mostra una configurazione di alta affidabilità e RE suggerita con tre database di standby di replica di lettura in tre zone di disponibilità e due regioni.

AlloyDB Omni con opzioni di backup e alta disponibilità tra regioni

Figura 1. AlloyDB Omni con opzioni di backup e alta disponibilità tra regioni.

Come illustrato nella Figura 1, la replica in streaming sincrona alle repliche locali (all'interno della stessa regione) fornisce alta affidabilità, mentre la replica in streaming asincrona a una replica remota separata geograficamente fornisce protezione per il ripristino di emergenza a livello regionale. Nell'intera configurazione, solo l'istanza principale può eseguire operazioni di lettura/scrittura, mentre le altre repliche possono gestire le query di lettura.

Configura la replica dall'istanza primaria alle repliche nella regione in modalità sincrona, mentre la replica alle repliche tra regioni deve essere configurata in modalità asincrona per evitare che la latenza influisca sulle prestazioni di scrittura dell'istanza primaria. In caso di errore a livello di regione, questa configurazione potrebbe comportare un RPO diverso da zero. Tuttavia, questa configurazione consente un RTO più rapido in caso di guasto. Questo perché il database primario non deve attendere la conferma dai database di standby remoti prima di eseguire il commit delle transazioni.

È possibile che i backup tra regioni aggiuntivi vengano eseguiti dai database di replica di lettura e quindi aggiungano ridondanza ai backup eseguiti dal database primario.

Backup delle repliche di lettura

Quando utilizzi i deployment Kubernetes, il deployment secondario nella regione alternativa viene configurato automaticamente con backup aggiuntivi. Quando utilizzi deployment non Kubernetes, puoi scegliere di eseguire il deployment dei backup in base alle esigenze della tua attività. Considera quanto segue:

  • Se il backup remoto potrebbe essere soggetto a errori a livello di regione, devi avviare backup aggiuntivi nelle regioni alternative.
  • Se hai bisogno di ridondanza del backup, devi eseguire backup delle repliche di lettura regionali.

Posizione della replica di lettura per supportare la disponibilità multizona

Nelle implementazioni non Kubernetes, puoi scegliere repliche di lettura specifiche da assumere il ruolo di primaria in caso di errore della primaria. L'operatore Kubernetes di AlloyDB Omni gestisce automaticamente il posizionamento dei nodi nelle zone e i nodi su cui devono essere implementati i pod. Alcune opzioni di configurazione che influiscono sul posizionamento, come l'affinità e la tolleranza dei pod, sono disponibili nella configurazione del database utilizzata per il deployment con l'operatore AlloyDB Omni.

Migrazione da un'architettura solo ad alta affidabilità a un'architettura ad alta affidabilità e RE

Per i deployment non Kubernetes, devi creare un nuovo standby in una nuova regione e aggiungere questa configurazione alla configurazione del cluster Patroni. Per i deployment Kubernetes, devi creare un nuovo deployment Kubernetes regionale, chiamato cluster di database secondario, e abilitare la replica tra data center.

Implementazione

Quando scegli un'architettura di riferimento per la disponibilità, tieni presente i seguenti vantaggi, limitazioni e opzioni.

Vantaggi

  • Protegge da errori a livello di zona e di istanza
  • Protegge dagli errori a livello di regione
  • RTO ridotto quando il database subisce un errore a livello di regione

Limitazioni

  • Puoi ridurre l'RPO per il ripristino regionale con la replica sincrona, ma questo approccio causa una latenza aggiuntiva per le prestazioni delle transazioni. Per il ripristino di emergenza e la replica remota delle regioni, ti consigliamo di utilizzare solo la replica asincrona.
  • La configurazione dello streaming WAL di PostgreSQL in modalità sincrona offre una perdita di dati pari a zero (RPO=0) durante il normale funzionamento o i tipici failover. Tuttavia, questo approccio non protegge dalla perdita di dati in situazioni specifiche di doppio errore, ad esempio quando tutte le istanze di standby vengono perse o diventano irraggiungibili dalla primaria e questo è immediatamente seguito da un riavvio della primaria.

Opzioni di protezione dei dati

Passaggi successivi