Proteggere i dati utilizzando la replica zonale

Seleziona una versione della documentazione:

Questa pagina descrive l'architettura di riferimento per l'alta affidabilità di AlloyDB Omni Enhanced Availability, che fornisce un'alta affidabilità eseguendo il deployment di una o più repliche di database all'interno della stessa regione che protegge da errori a livello di nodo o di zona.

Casi d'uso

Questa architettura di riferimento per la disponibilità è adatta ai seguenti casi d'uso:

  • Applicazioni business critical che richiedono RTO e RPO inferiori.
  • Vuoi eseguire il deployment di una replica in un'altra zona o in un altro nodo che fornisca un'alta disponibilità per i tuoi database e protegga da errori a livello di istanza, server e zona.
  • Vuoi proteggerti da errori dell'utente e danneggiamento dei dati (utilizzando i backup).

Come funziona l'architettura di riferimento

La disponibilità avanzata si aggiunge alla disponibilità standard aggiungendo istanze di repliche di lettura all'interno della regione per abilitare l'alta affidabilità (HA) che riduce il Recovery Time Objective (RTO). Questo approccio riduce anche il Recovery Point Objective (RPO) consentendo lo streaming delle modifiche transazionali alla replica.

L'alta affidabilità in AlloyDB Omni utilizza almeno due istanze di database. Un'istanza funge da database principale e supporta le operazioni di lettura e scrittura. Le istanze rimanenti fungono da repliche di lettura e operano in modalità di sola lettura.

Di seguito sono riportati i concetti importanti relativi all'alta disponibilità:

  • Il failover è la procedura durante un'interruzione non pianificata in cui l'istanza principale non funziona o diventa non disponibile e la replica di standby viene attivata per assumere la modalità principale (lettura-scrittura). Questo processo è chiamato promozione. In genere, in questi scenari, quando il server o il database principale torna online, il database deve essere ricompilato e quindi deve fungere da standby. Per garantire un tempo di attività elevato, sono in atto meccanismi per rendere automatici i failover.
  • Uno switchover, noto anche come inversione dei ruoli, è una procedura utilizzata per cambiare le modalità tra il database principale e uno dei database di standby, in modo che il database principale diventi di standby e il database di standby diventi principale. In genere, gli switchover avvengono in modo controllato e graduale e possono essere avviati per una serie di motivi, ad esempio per consentire il tempo di inattività e l'applicazione di patch al database principale precedente. Gli switchover graduali devono consentire un futuro switchback senza dover reinizializzare il nuovo standby o altri aspetti della configurazione della replica.

Opzioni di alta affidabilità

Negli ambienti Kubernetes, per supportare l'alta disponibilità, puoi eseguire il deployment di AlloyDB Omni utilizzando gli operatori AlloyDB Omni Kubernetes Per ulteriori informazioni, consulta Gestire l'alta affidabilità in Kubernetes.

Nota: Patroni e HAProxy sono strumenti di terze parti non commerciali e sono compatibili con AlloyDB Omni.

Ti consigliamo di avere almeno due database di standby in modo che la perdita di un database non influisca sull'alta affidabilità del cluster. In questa modalità, hai almeno una coppia di alta disponibilità in caso di failover o durante qualsiasi manutenzione pianificata di un nodo.

Per pianificare le dimensioni e la forma del deployment di AlloyDB Omni, consulta Pianificare l'installazione di AlloyDB Omni su una VM.

Bilanciatori del carico

Un altro meccanismo importante che facilita le procedure di switchover e failover è la presenza di un bilanciatore del carico.

L'operatore Kubernetes esegue il deployment del proprio bilanciatore del carico, che si comporta in modo simile, creando un servizio per il database che punta al bilanciatore del carico per renderlo trasparente per l'utente.

Alta affidabilità

I database di repliche di lettura di cui è stato eseguito il deployment all'interno di una regione forniscono un'alta affidabilità in caso di errore del database principale. Quando si verifica un errore del database principale, il database di standby viene promosso per sostituire il database principale e l'applicazione continua con un'interruzione minima o nulla.

In genere, è consigliabile eseguire controlli regolari annuali o semestrali sotto forma di switchover per assicurarsi che tutte le applicazioni che si basano su questi database siano ancora in grado di connettersi e rispondere in un periodo di tempo adeguato.

La protezione a livello di zona può essere ottenuta utilizzando uno dei due tipi di deployment posizionando una delle repliche di lettura di standby in una zona di disponibilità diversa dal database principale.

Un ulteriore vantaggio di avere repliche di lettura è la possibilità di scaricare le operazioni di sola lettura sui database di standby, che possono fungere da database di reporting utilizzando dati aggiornati. Questo approccio riduce il carico e l'overhead sul database principale di lettura-scrittura.

Configurazione di backup e alta affidabilità

Le repliche di lettura possono essere configurate in più zone che forniscono un'alta affidabilità. Sebbene forniscano RTO e RPO bassi, non proteggono da determinate interruzioni, come il danneggiamento logico dei dati, ad esempio eliminazioni accidentali di tabelle o aggiornamenti errati dei dati. Pertanto, oltre alla configurazione dell'alta disponibilità, è necessario eseguire backup regolari. Per ulteriori dettagli, consulta la documentazione sull'architettura di disponibilità standard.

La Figura 1 mostra una configurazione di alta disponibilità consigliata con due database di standby di repliche di lettura in due zone di disponibilità diverse.

AlloyDB Omni con opzioni di backup e alta affidabilità

Figura 1. AlloyDB Omni con opzioni di backup e alta affidabilità.

Per proteggerti dalla perdita di dati in caso di errore dell'istanza principale, è necessario configurare la replica in modalità sincrona. Sebbene questo metodo fornisca una protezione dei dati efficace, può influire sulle prestazioni del database principale perché tutti i commit devono essere scritti sia nel database principale sia in tutti i database di standby sincronizzati. Per questa configurazione è fondamentale una connessione di rete a bassa latenza tra queste istanze di database.

Deployment di alta disponibilità di Kubernetes

Per i deployment di Kubernetes, modificando e aggiungendo alcuni attributi di base al file di deployment di AlloyDB Omni, puoi aggiungere repliche di standby di failover o di lettura per consentire l'errore del database principale. È possibile configurare una replica di standby di failover e di sola lettura e l'operatore si occupa del provisioning e della pubblicazione del servizio. L'operatore automatizza anche molti dei processi di alta disponibilità, come la ricompilazione dei database di standby dopo un failover e l'utilizzo dei meccanismi di riparazione integrati nel motore AlloyDB Omni Kubernetes.

In un deployment di Kubernetes, la disponibilità dell'infrastruttura e delle applicazioni beneficia delle funzionalità integrate di Kubernetes che si occupano degli errori di nodi e pod, tra cui:

Oltre alla protezione integrata, l'operatore espone i seguenti parametri per influenzare il rilevamento di un database principale o di standby non riuscito:

  • healthcheckPeriodSeconds: il tempo tra i controlli di integrità. Il valore predefinito è 30 secondi.
  • autoFailoverTriggerThreshold: il numero di controlli di integrità non riusciti consecutivi prima di avviare il failover. Il valore predefinito è 3.

Per ulteriori informazioni, consulta Gestire l'alta affidabilità in Kubernetes.

Implementazione

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

Vantaggi

  • Protegge da errori dell'istanza.
  • Protegge da errori del server.
  • Protegge da errori della zona.
  • RTO notevolmente ridotto rispetto alla disponibilità standard.

Limitazioni

  • Nessuna protezione aggiuntiva per i disastri regionali.
  • Potenziale impatto sulle prestazioni del database principale a causa della replica sincrona.
  • 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 failover tipici. 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 dal database principale e questa situazione è immediatamente seguita da un riavvio del database principale.

Alternative

Passaggi successivi