Questa pagina descrive l'alta disponibilità e gli strumenti che consigliamo di utilizzare.
Informazioni sulla resilienza dei dati
Puoi considerare la resilienza dei dati in termini di disponibilità, tempo di ripristino del servizio e perdita di dati. La disponibilità viene solitamente misurata in termini di uptime ed espressa come percentuale del tempo in cui il database è disponibile. Ad esempio, per ottenere una disponibilità del 99,99%, il database non può essere inattivo per più di 52,6 minuti all'anno o 4,38 minuti al mese. Il tempo necessario per ripristinare il servizio dopo un'interruzione è chiamato Recovery Time Objective (RTO). La quantità di perdita di dati accettabile a causa di un'interruzione viene chiamata Recovery Point Objective (RPO) ed è espressa come il periodo di tempo per cui le transazioni vengono perse. Ad esempio, un RPO di 10 minuti indica che, in caso di errore, potresti perdere fino a 10 minuti di dati.
È comune impostare un target di disponibilità o un obiettivo del livello di servizio (SLO) insieme ai target per RTO e RPO. Ad esempio, per un determinato carico di lavoro, potresti impostare lo SLO sul 99,99% e richiedere anche un RPO pari a 0, nessuna perdita di dati in caso di errore e un RTO di 30 secondi. Per un altro carico di lavoro, puoi impostare lo SLO su 99,9%, il RPO su 5 minuti e il RTO su 10 minuti.
Puoi implementare la resilienza di base del database con i backup del database. AlloyDB Omni supporta i backup utilizzando pgBackRest e archivia anche i file del log Write Ahead (WAL) del database per ridurre al minimo la perdita di dati. Con questo approccio, se il database principale si arresta in modo anomalo, può essere ripristinato da un backup con un RPO di pochi minuti e un RTO da pochi minuti a diverse ore, a seconda delle dimensioni del database.
Per requisiti RPO e RTO più rigorosi, puoi configurare AlloyDB Omni in una configurazione ad alta disponibilità utilizzando Patroni. In questa architettura, esiste un database principale e due database di riserva o replica. Puoi configurare AlloyDB Omni in modo da utilizzare la replica dinamica PostgreSQL standard per assicurarti che ogni transazione eseguita sul database principale sia replicata in modo sincrono in entrambi i database di standby. Ciò fornisce un RPO pari a zero e un RTO inferiore a 60 secondi per la maggior parte degli scenari di errore.
A seconda della configurazione del cluster, la replica sincrona potrebbe influire sul tempo di risposta delle transazioni e puoi scegliere di rischiare una piccola perdita di dati. Ad esempio, puoi avere un RPO diverso da zero in cambio di una latenza transazionale inferiore implementando la disponibilità elevata con la replica asincrona anziché sincrona. A causa del potenziale impatto della replica sincrona sulla latenza delle transazioni, le architetture ad alta disponibilità vengono quasi sempre implementate all'interno di un unico data center o tra data center vicini (a distanza di decine di chilometri/meno di 10 millisecondi di latenza). Tuttavia, tieni presente che questa documentazione utilizza la replica sincrona come impostazione predefinita.
Per il disaster recovery, ovvero la protezione contro la perdita di un data center o di una regione in cui sono presenti più data center vicini, AlloyDB Omni può essere configurato con la replica streaming asincrona dalla regione principale a una regione secondaria, in genere a centinaia o migliaia di chilometri di distanza o a distanza di decine di millisecondi. In questa configurazione, la regione principale è configurata con la replica streaming sincrona tra i database principale e di standby all'interno della regione e la replica streaming asincrona è configurata dalla regione principale a una o più regioni secondarie. AlloyDB Omni può essere configurato nella regione secondaria con più istanze di database per assicurarsi che sia protetto immediatamente dopo un failover dalla regione principale.
Come funziona l'alta disponibilità
Le tecniche e gli strumenti specifici utilizzati per implementare l'alta disponibilità per i database possono variare a seconda del sistema di gestione del database. Di seguito sono riportate alcune delle tecniche e degli strumenti di solito coinvolti nell'implementazione dell'alta disponibilità per i database, che può variare a seconda del sistema di gestione del database:
Redundanza: la replica del database su più server o regioni geografiche offre opzioni di failover in caso di guasto di un'istanza principale.
Failover automatico: meccanismo per rilevare gli errori e passare senza problemi a una replica sana, riducendo al minimo i tempi di inattività. Le query vengono instradate in modo che le richieste dell'applicazione raggiungano il nuovo nodo principale.
Continuità dei dati: vengono implementate misure di salvaguardia per proteggere l'integrità dei dati in caso di errori. Sono incluse le tecniche di replica e i controlli di coerenza dei dati.
Clustering: il clustering prevede il raggruppamento di più server di database in modo che lavorino insieme come un unico sistema. In questo modo, tutti i nodi del cluster sono attivi e gestiscono le richieste, garantendo il bilanciamento del carico e la ridondanza.
Piano di riserva: metodi per eseguire il fallback all'architettura originale utilizzando i nodi principali e di replica pre-failover nelle loro capacità originali.
Bilanciamento del carico: la distribuzione delle richieste del database su più istanze migliora le prestazioni e gestisce l'aumento del traffico.
Monitoraggio e avvisi: gli strumenti di monitoraggio rilevano problemi come guasti del server, alta latenza, esaurimento delle risorse e attivano avvisi o procedure di failover automatico.
Backup e ripristino: i backup possono essere utilizzati per ripristinare i database a uno stato precedente in caso di danneggiamento dei dati o di errore catastrofico.
Pool di connessioni (facoltativo): ottimizza le prestazioni e la scalabilità delle applicazioni che interagiscono con i tuoi database.
Strumenti di alta disponibilità
Patroni è uno strumento di gestione dei cluster open source per i database PostgreSQL progettato per gestire e automatizzare l'alta disponibilità per i cluster PostgreSQL. Patroni utilizza vari sistemi di consenso distribuito come etcd, Consul o Zookeeper per coordinare e gestire lo stato del cluster. Alcune funzionalità e componenti chiave di Patroni includono l'alta disponibilità con failover automatico, elezione del leader, replica e recupero. Patroni viene eseguito insieme al servizio PostgreSQL sulle istanze del server di database, gestendone lo stato, i failover e la replica per garantire alta disponibilità e affidabilità.
Patroni utilizza un sistema di consenso distribuito per archiviare i metadati e gestire il cluster. In questa guida utilizziamo un Distributed Configuration Store (DCS) chiamato etcd. Uno degli utilizzi di etcd è memorizzare e recuperare informazioni su sistemi distribuiti come configurazione, stato di salute e stato corrente, garantendo una configurazione coerente su tutti i nodi.
High Availability Proxy (HAProxy) è un software open source utilizzato per il bilanciamento del carico e il proxy di applicazioni basate su TCP e HTTP, utilizzato per migliorare le prestazioni e l'affidabilità delle applicazioni web distribuendo le richieste in arrivo su più server. HAProxy offre il bilanciamento del carico distribuendo il traffico di rete su più server. HAProxy mantiene inoltre lo stato di integrità dei server di backend a cui si connette eseguendo controlli di integrità. Se un server non supera un controllo di integrità, HAProxy smette di inviarvi traffico fino a quando non supera di nuovo i controlli di integrità.
Considerazioni sulla replica sincrona e asincrona
In un cluster PostgreSQL gestito da Patroni, la replica può essere configurata sia in modalità sincrona sia in modalità asincrona. Per impostazione predefinita, Patroni utilizza la replica dinamica asincrona. Per requisiti RPO rigorosi, consigliamo di utilizzare la replica sincrona.
La replica sincrona in PostgreSQL garantisce la coerenza dei dati aspettando che le transazioni vengano scritte sia nel database principale sia in almeno un database standby sincrono prima di eseguire il commit. La replica sincrona garantisce che i dati non vengano persi in caso di guasto del sistema principale, garantendo una solida durabilità e coerenza dei dati. Il principale attende i riconoscimenti dal standby sincrono, che può comportare una latenza più elevata e un throughput potenzialmente inferiore a causa del tempo di percorrenza aggiunto. Ciò può ridurre la produttività complessiva del sistema, soprattutto in caso di carico elevato.
La replica asincrona consente di eseguire il commit delle transazioni sul cluster primario senza attendere gli acknowledgment dai cluster di standby. Il principale invia i record WAL ai standby, che li applicano in modo asincrono. Questo approccio asincrono riduce la latenza di scrittura e migliora le prestazioni, ma comporta il rischio di perdita di dati se il principale non funziona prima che il standby abbia avuto il tempo di recuperare. Le istanze di standby potrebbero essere in ritardo rispetto a quella principale, il che potrebbe causare potenziali incoerenze durante il failover.
La scelta tra la replica sincrona e quella asincrona in un cluster Patroni dipende dai requisiti specifici per la durabilità, la coerenza e le prestazioni dei dati. La replica sincrona è preferibile in scenari in cui l'integrità dei dati e la perdita minima di dati sono fondamentali, mentre la replica asincrona è adatta a ambienti in cui le prestazioni e una latenza inferiore sono prioritarie. Puoi configurare una soluzione mista che prevede un cluster di tre nodi con un standby sincrono nella stessa regione, ma in una zona o in un data center diverso nelle vicinanze, e un secondo standby asincrono in una regione diversa o in un data center più distante per proteggerti da potenziali interruzioni a livello di regione.