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 misurata in genere in termini di uptime ed espressa come la percentuale di tempo in cui il database è disponibile. Ad esempio, per raggiungere 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 di ripristino del 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 o RPO ed è espressa come la quantità di tempo per cui 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.
È comune impostare un obiettivo di disponibilità, o obiettivo del livello di servizio (SLO), insieme agli obiettivi per RTO e RPO. Ad esempio, per un determinato workload, potresti impostare l'SLO al 99,99% e richiedere anche un RPO di 0, nessuna perdita di dati in caso di errore e un RTO di 30 secondi. Per un altro workload, potresti impostare l'SLO al 99,9%, l'RPO a 5 minuti e l'RTO a 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 di log Write Ahead Log (WAL) del database per ridurre al minimo la perdita di dati. Con questo approccio, se il database principale non è disponibile, 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 affidabilità utilizzando Patroni. In questa architettura, è presente un database principale e due database di standby o di replica. Puoi configurare AlloyDB Omni in modo che utilizzi la replica di streaming PostgreSQL standard per garantire che ogni transazione di cui viene eseguito il commit sul database principale venga replicata in modo sincrono in entrambi i database di standby. In questo modo si ottiene un RPO pari a zero e un RTO inferiore a sessanta 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 quantità di perdita di dati. Ad esempio, puoi avere un RPO diverso da zero in cambio di una latenza transazionale inferiore implementando l'alta affidabilità con la replica asincrona anziché sincrona. A causa del potenziale impatto della replica sincrona sulla latenza delle transazioni, le architetture ad alta affidabilità vengono quasi sempre implementate all'interno di un singolo data center o tra data center vicini (a decine di km di distanza/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, AlloyDB Omni può essere configurato con la replica di streaming asincrona dalla regione principale a una regione secondaria, in genere a centinaia o migliaia di km di distanza o a decine o centinaia di millisecondi di distanza. In questa configurazione, la regione principale è configurata con la replica di streaming sincrona tra i database principali e di standby all'interno della regione e la replica di 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 garantire che sia protetto immediatamente dopo un failover dalla regione principale.
Come funziona l'alta affidabilità
Le tecniche e gli strumenti specifici utilizzati per implementare l'alta affidabilità per i database possono variare a seconda del sistema di gestione dei database. Di seguito sono riportate alcune delle tecniche e degli strumenti generalmente coinvolti nell'implementazione dell'alta affidabilità 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 principale.
Continuità dei dati: vengono implementate salvaguardie per proteggere l'integrità dei dati durante gli errori. Sono incluse tecniche di replica e controlli di coerenza dei dati.
Clustering: il clustering prevede il raggruppamento di più server di database per lavorare insieme come un unico sistema. In questo modo, tutti i nodi del cluster sono attivi e gestiscono le richieste, fornendo bilanciamento del carico e ridondanza.
Fallback: metodi per ripristinare l'architettura originale utilizzando i nodi principali 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 errori del server, latenza elevata, 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 errori irreversibili.
Pool di connessioni (facoltativo): ottimizza le prestazioni e la scalabilità delle applicazioni che interagiscono con i database.
Strumenti di alta affidabilità
Patroni è uno strumento di gestione dei cluster open source per i database PostgreSQL progettato per gestire e automatizzare l'alta affidabilità 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 affidabilità con failover automatico, l'elezione del leader, la replica e il ripristino. Patroni viene eseguito insieme al servizio PostgreSQL sulle istanze del server di database, gestendo la loro integrità, i failover e la replica per garantire alta affidabilità e affidabilità.
Patroni utilizza un sistema di consenso distribuito per archiviare i metadati e gestire il cluster. In questa guida utilizziamo un archivio di configurazione distribuita (DCS) chiamato etcd. Uno degli utilizzi di etcd è archiviare e recuperare informazioni sui sistemi distribuiti, come configurazione, integrità 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 delle 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 inviare 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 in modalità sincrona e asincrona. Per impostazione predefinita, Patroni utilizza la replica di streaming asincrona. Per requisiti RPO rigorosi, ti consigliamo di utilizzare la replica sincrona.
La replica sincrona in PostgreSQL garantisce la coerenza dei dati attendendo che le transazioni vengano scritte sia sul database principale sia su almeno un database di standby sincrono prima di eseguire il commit. La replica sincrona garantisce che i dati non vengano persi in caso di errore principale, fornendo una forte durabilità e coerenza dei dati. Il database principale attende le conferme dal database di standby sincrono, il che può comportare una latenza maggiore e un throughput potenzialmente inferiore a causa del tempo di round trip aggiuntivo. Ciò può ridurre il throughput complessivo del sistema, soprattutto in caso 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 database principale invia i record WAL ai database di 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 principale non funziona prima che il database di standby sia aggiornato. I database di standby potrebbero essere in ritardo rispetto al database principale, il che potrebbe causare incoerenze durante il failover.
La scelta tra replica sincrona e asincrona in un cluster Patroni dipende dai requisiti specifici per la durabilità, la coerenza e le prestazioni dei dati. La replica sincrona è preferibile negli scenari in cui l'integrità dei dati e la perdita minima di dati sono fondamentali, mentre la replica asincrona è adatta agli ambienti in cui le prestazioni e la latenza inferiore sono prioritarie. Puoi configurare una soluzione mista che prevede un cluster a tre nodi con un database di standby sincrono nella stessa regione, ma in una zona o in un data center vicino diverso, e un secondo database di standby asincrono in una regione diversa o in un data center più distante per proteggerti da potenziali interruzioni regionali.