Gli obiettivi principali di una configurazione multi-datacenter (o multi-DC) — indipendentemente dal fatto che l'ecosistema del database sia SQL (PostgreSQL, MySQL) o NoSQL (MongoDB, Cassandra) per citarne solo alcuni — sono la bassa latenza per gli utenti finali, Alta disponibilità e ripristino di emergenza. Al centro di un tale ambiente c'è la capacità di replicare i dati, in modi che ne garantiscano la durabilità (come nota a margine, i parametri di configurazione della durabilità di Cassandra sono simili a quelli usati da PostgreSQL). I vari requisiti di replica saranno discussi di seguito, tuttavia, i casi estremi saranno lasciati ai curiosi per ulteriori ricerche.
La replica tramite log shipping asincrono è disponibile in PostgreSQL da molto tempo e la replica sincrona introdotta nella versione 9.1 ha aperto un insieme completamente nuovo di opzioni agli sviluppatori di strumenti di gestione di PostgreSQL.
Cose da considerare
Un modo per comprendere la complessità di un'implementazione multi-DC di PostgreSQL è imparare dalle soluzioni implementate per altri sistemi di database, tenendo presente che PostgreSQL insiste per essere conforme ad ACID.
Una configurazione multi-DC include, nella maggior parte dei casi, almeno un data center nel cloud. Sebbene i fornitori di servizi cloud si assumano l'onere di gestire la replica del database per conto dei loro clienti, di solito non corrispondono alle funzionalità disponibili in strumenti di gestione specializzati. Ad esempio, con molte aziende che adottano soluzioni cloud ibride e/o multi-cloud, oltre alla loro infrastruttura locale esistente, uno strumento multi-DC dovrebbe essere in grado di gestire un ambiente così misto.
Inoltre, per ridurre al minimo i tempi di inattività durante un failover, il sistema di gestione PostgreSQL dovrebbe essere in grado di richiedere (tramite una chiamata API) un aggiornamento DNS, in modo che le richieste del database vengano instradate al nuovo cluster master.
Le reti che si estendono su vaste aree geografiche sono connessioni ad alta latenza e tutte le soluzioni devono scendere a compromessi:dimenticare la replica sincrona e utilizzare un primario con molte repliche di lettura. Consulta gli studi AWS MongoDB e Multiplenines/Galera Cluster per un'analisi approfondita degli effetti della rete sulla replica. In una nota correlata, uno strumento ingegnoso per testare la latenza tra le posizioni è Wonder Network Ping Statistics.
Sebbene la natura ad alta latenza della WAN non possa essere modificata, l'esperienza dell'utente può essere notevolmente migliorata garantendo che le letture vengano servite da una replica di lettura vicino alla posizione dell'utente, tuttavia con alcuni avvertimenti. Spostando le repliche dal primario, le scritture vengono ritardate e quindi dobbiamo eliminare la replica sincrona. La soluzione deve anche essere in grado di aggirare altri problemi come la coerenza della lettura dopo la scrittura e le letture secondarie obsolete dovute alla perdita di connessione.
Per ridurre al minimo l'RTO, i dati devono essere replicati su uno storage durevole che sia anche in grado di fornire un throughput di lettura elevato e, secondo Citus Data, un'opzione che soddisfa tali requisiti è AWS S3.
La nozione stessa di data center multiplo implica che il sistema di gestione del database deve essere in grado di presentare al DBA una visione globale di tutti i data center e dei vari cluster PostgreSQL al loro interno, gestire più versioni di PostgreSQL e configurare la replica tra di loro.
Quando si replicano le scritture nei data center regionali, è necessario monitorare il ritardo di propagazione. Se il ritardo supera una soglia, deve essere attivato un allarme che indica che la replica contiene dati non aggiornati. Lo stesso principio si applica alla replica multimaster asincrona.
In una configurazione sincrona, l'elevata latenza o le interruzioni della rete possono causare ritardi nel soddisfare le richieste dei client in attesa del completamento del commit, mentre nelle configurazioni asincrone esistono rischi di split-brain o prestazioni ridotte per un periodo di tempo prolungato. Il cervello diviso e i ritardi nei commit sincroni sono inevitabili anche con soluzioni di replica consolidate, come spiegato nell'articolo Cluster di database geodistribuiti con Galera.
Un'altra considerazione è il supporto del fornitore:al momento della stesura di questo articolo, AWS non supporta le repliche tra regioni di PostgreSQL.
I sistemi di gestione intelligenti dovrebbero monitorare la latenza di rete tra i data center e consigliare o modificare le modifiche, ad es. la replica sincrona è perfetta tra le zone di disponibilità AWS in cui i data center sono collegati tramite reti in fibra. In questo modo una soluzione può ottenere una perdita di dati pari a zero e può anche implementare la replica master-master insieme al bilanciamento del carico. Tieni presente che AWS Aurora PostgreSQL al momento non fornisce un'opzione di replica master-master.
Decidi il livello di replica:cluster, database, tabella. I criteri decisionali dovrebbero includere i costi della larghezza di banda.
Implementa la replica in cascata per aggirare le interruzioni della rete che possono impedire alle repliche di ricevere aggiornamenti dal master a causa della distanza geografica.
Soluzioni
Prendendo in considerazione tutti i requisiti, individuare i prodotti più adatti al lavoro. Una nota di cautela però:ogni soluzione viene fornita con i propri avvertimenti che devono essere affrontati seguendo le raccomandazioni nella documentazione del prodotto. Vedi ad esempio il requisito del monitoraggio BDR.
La documentazione ufficiale di PostgreSQL contiene un elenco di applicazioni open source non commerciali e un elenco esteso che include soluzioni commerciali closed source può essere trovato nella pagina wiki Replica, Clustering e Connection Pooling. Alcuni di questi strumenti sono stati esaminati in modo più dettagliato nell'articolo Top PG Clustering HA Solutions for PostgreSQL.
Non esiste una soluzione chiavi in mano, ma alcuni prodotti possono fornire la maggior parte delle funzionalità, soprattutto quando si lavora con il fornitore.
Ecco un elenco non esaustivo:
- Citus Data fornisce la propria build PostgreSQL, migliorata con straordinarie funzionalità aziendali e una profonda integrazione con AWS.
- EnterpriseDB offre un'ampia suite di servizi che possono essere combinati per soddisfare la maggior parte dei requisiti. La maggior parte delle informazioni si trova nella documentazione del prodotto.
- Postgres-BDR è un potente strumento di replica progettato specificamente per cluster geograficamente distribuiti, tuttavia non si integra con nessun provider di servizi cloud.
- ClusterControl viene fornito con un impressionante set di funzionalità per la gestione di PostgreSQL. Ha anche un'integrazione cloud limitata.
- ElephantSQL funziona su molti provider cloud. Tuttavia, non è disponibile alcuna opzione per una configurazione in sede.
- Crunchy PostgreSQL for Kubernetes è un prodotto indipendente dal cloud basato su PostgreSQL a monte.
Conclusione
Come abbiamo visto, quando si tratta di scegliere una soluzione multi-datacenter PostgreSQL, non esiste una soluzione adatta a tutti. Spesso è d'obbligo scendere a compromessi. Tuttavia, una buona comprensione dei requisiti e delle implicazioni può fare molto per prendere una decisione informata.
Rispetto ai dati statici (di sola lettura), una soluzione per i database deve considerare la replica degli aggiornamenti (scritture). La letteratura che descrive le soluzioni di replica sia SQL che NoSQL insiste sull'utilizzo di un'unica fonte di verità per le scritture con molte repliche al fine di evitare problemi come il cervello diviso e la coerenza lettura dopo scrittura.
Infine, l'interoperabilità è un requisito fondamentale considerando che le configurazioni multi-DC possono estendersi a data center situati in sede e vari provider di servizi cloud.
