Questa pagina descrive l'alta affidabilità e gli strumenti che consigliamo di utilizzare.
Informazioni sulla resilienza dei dati
Puoi pensare alla 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 di 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 viene chiamato Recovery Time Objective o RTO. La quantità accettabile di perdita di dati dovuta a un'interruzione viene chiamata Recovery Point Objective (RPO) ed è espressa come il periodo di tempo per il quale le transazioni vengono perse. Ad esempio, un RPO di 10 minuti significa che in caso di errore potresti perdere fino a 10 minuti di dati.
È prassi comune impostare un target di disponibilità, o obiettivo del livello di servizio (SLO), insieme ai target per RTO e RPO. Ad esempio, per un determinato carico di lavoro, puoi impostare l'SLO al 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, potresti impostare l'SLO su 99,9%, l'RPO su 5 minuti e l'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 Write Ahead Log (WAL) del database per ridurre al minimo la perdita di dati. Con questo approccio, se il database principale non funziona, può essere ripristinato da un backup con un RPO di minuti e un RTO di minuti o 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 standby o di replica. Puoi configurare AlloyDB Omni in modo che utilizzi la replica in streaming PostgreSQL standard per garantire che ogni transazione di cui viene eseguito il commit sul database primario venga replicata in modo sincrono in entrambi i database di standby. In questo modo, il RPO è pari a zero e il 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 per le transazioni e puoi scegliere di rischiare una piccola quantità di perdita di dati. Ad esempio, puoi avere un RPO diverso da zero in cambio di una latenza transazionale inferiore implementando l'alta disponibilità con la replica asincrona anziché quella 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 singolo data center o tra data center vicini (distanti decine di chilometri/con una latenza inferiore a 10 millisecondi). Tuttavia, tieni presente che questa documentazione utilizza la replica sincrona come impostazione predefinita.
Per il ripristino di emergenza, ovvero la protezione dalla perdita di un data center o di una regione in cui sono presenti più data center vicini tra loro, AlloyDB Omni può essere configurato con la replica asincrona in streaming dalla regione primaria a una regione secondaria, in genere a centinaia o migliaia di chilometri di distanza o a decine o centinaia di millisecondi di distanza. In questa configurazione, la regione primaria è configurata con la replica di streaming sincrona tra i database primario e di standby all'interno della regione e la replica di streaming asincrona è configurata dalla regione primaria a una o più regioni secondarie. AlloyDB Omni può essere configurato nella regione secondaria con più istanze di database per garantire la protezione 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 dei database. Di seguito sono riportate alcune delle tecniche e degli strumenti solitamente coinvolti nell'implementazione dell'alta disponibilità per i database, che possono variare a seconda del sistema di gestione dei database:
Ridondanza: la replica del database su più server o regioni geografiche fornisce opzioni di failover se un'istanza principale non è disponibile.
Failover automatico: meccanismo per rilevare gli errori e passare senza problemi a una replica integra, riducendo al minimo i tempi di inattività. Le query vengono instradate in modo che le richieste dell'applicazione raggiungano il nuovo nodo primario.
Continuità dei dati: vengono implementate misure di protezione per salvaguardare l'integrità dei dati durante gli 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 per funzionare insieme come un unico sistema. In questo modo, tutti i nodi del cluster sono attivi e gestiscono le richieste, il che fornisce bilanciamento del carico e ridondanza.
Fallback: metodi per eseguire il fallback all'architettura originale utilizzando i nodi primari e di replica pre-failover nelle loro capacità originali.
Bilanciamento del carico: la distribuzione delle richieste di database su più istanze migliora le prestazioni e gestisce l'aumento del traffico.
Monitoraggio e avvisi: gli strumenti di monitoraggio rilevano problemi come l'errore del server, l'alta latenza, l'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 guasto 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, l'elezione del leader, la replica e il recupero. Patroni viene eseguito insieme al servizio PostgreSQL sulle istanze del server di database, gestendo l'integrità, 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 è l'archiviazione e il recupero di informazioni sui sistemi distribuiti, come configurazione, stato e stato attuale, 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 entrata su più server. HAProxy offre il bilanciamento del carico distribuendo il traffico di rete su più server. HAProxy mantiene anche 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 inviargli traffico finché 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 in modalità sincrona e asincrona. Per impostazione predefinita, Patroni utilizza la replica in streaming asincrona. Per requisiti RPO rigorosi, consigliamo di utilizzare la replica sincrona.
La replica sincrona in PostgreSQL garantisce la coerenza dei dati in quanto attende che le transazioni vengano scritte sia nel database primario sia in almeno uno standby sincrono prima del commit. La replica sincrona garantisce che i dati non vengano persi in caso di errore principale, fornendo una forte durabilità e coerenza dei dati. L'istanza principale attende gli acknowledgement dall'istanza di standby sincrona, il che può comportare una latenza più elevata e un throughput potenzialmente inferiore a causa deltempo di round tripno aggiuntivo. Ciò può ridurre la velocità effettiva complessiva del sistema, soprattutto in condizioni di carico elevato.
La replica asincrona consente di eseguire il commit delle transazioni sul cluster principale senza attendere le conferme dai cluster di standby. Il nodo primario invia i record WAL agli 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 database primario non funziona prima che lo standby sia stato sincronizzato. Gli standby potrebbero essere in ritardo rispetto al primario, il che potrebbe causare potenziali incoerenze durante il failover.
La scelta tra la replica sincrona e asincrona in un cluster Patroni dipende dai requisiti specifici di durabilità, coerenza e rendimento 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 ad ambienti in cui le prestazioni e la latenza inferiore sono prioritari. Puoi configurare una soluzione mista che prevede un cluster di tre nodi con uno standby sincrono nella stessa regione, ma in una zona o un data center vicino diverso, 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.