Di seguito è riportato un estratto dal nostro whitepaper "Gestione e automazione PostgreSQL con ClusterControl" che può essere scaricato gratuitamente.
Nota di revisione: tieni presente che i termini utilizzati in questo blog Master-Slave sono sinonimi di termini Master-Standby utilizzati da PostgreSQL. Stiamo usando Master-Slave per mantenere il parallelismo con altre tecnologie.
Per la configurazione HA possiamo avere diverse architetture, ma quelle di base sarebbero master-slave e master-master. I server di database possono collaborare per consentire a un secondo server di subentrare rapidamente in caso di guasto del server primario (alta disponibilità ), o per consentire a più computer di fornire gli stessi dati (bilanciamento del carico).
Architetture Master-Slave PostgreSQL
Queste architetture ci consentono di mantenere un database master con uno o più server in standby pronti a rilevare le operazioni in caso di guasto del server primario. Questi database in standby rimarranno sincronizzati (o quasi sincronizzati) con il master.
La replica tra master e slave può essere effettuata tramite istruzioni SQL (standby logici) o tramite modifiche interne alla struttura dei dati (standby fisici). PostgreSQL utilizza un flusso di record WAL (write-ahead log) per mantenere sincronizzati i database in standby. Se il server principale si guasta, lo standby contiene quasi tutti i dati del server principale e può essere rapidamente trasformato nel nuovo server di database master. Questo può essere sincrono o asincrono e può essere fatto solo per l'intero server del database.
L'impostazione della replica in streaming è un'attività che richiede alcuni passaggi da seguire scrupolosamente. Per questi passaggi e ulteriori informazioni su questo argomento, vedere:Diventare un DBA PostgreSQL - Come impostare la replica in streaming per l'elevata disponibilità.
Dalla versione 10, PostgreSQL include l'opzione per impostare la replica logica.
La replica logica consente a un server di database di inviare un flusso di modifiche ai dati a un altro server. La replica logica di PostgreSQL costruisce un flusso di modifiche logiche dei dati dal WAL. La replica logica consente di replicare le modifiche ai dati delle singole tabelle. Non richiede che un server particolare sia designato come master o replica, ma consente ai dati di fluire in più direzioni.
È possibile trovare ulteriori informazioni sulla replica logica:Blog:una panoramica della replica logica in PostgreSQL.
Per garantire in modo efficace un'elevata disponibilità, non è sufficiente disporre di un'architettura master-slave. Abbiamo anche bisogno di abilitare una qualche forma automatica di failover, quindi se qualcosa fallisce possiamo avere il minor ritardo possibile nel riprendere la normale funzionalità. PostgreSQL non include un meccanismo di failover automatico per identificare gli errori nel database master e notificare al salve di assumerne la proprietà, quindi ciò richiederà un po' di lavoro da parte del DBA. Dovresti lavorare su uno script che includa il comando pg_ctl promote, che promuoverà lo slave come nuovo master. Esistono anche alcuni strumenti di terze parti per questa automazione. Molti di questi strumenti esistono e sono ben integrati con le strutture del sistema operativo necessarie per il successo del failover, come la migrazione degli indirizzi IP.
Dopo che si verifica un failover, è necessario modificare l'applicazione di conseguenza per lavorare con il nuovo master. Avrai anche un solo server funzionante, quindi è necessario ricreare l'architettura master-slave, quindi torniamo alla stessa situazione normale che avevamo prima del problema.
Scarica il whitepaper oggi Gestione e automazione di PostgreSQL con ClusterControlScopri ciò che devi sapere per distribuire, monitorare, gestire e ridimensionare PostgreSQLScarica il whitepaperArchitetture Master-Master PostgreSQL
Questa architettura fornisce un modo per ridurre al minimo l'impatto di un errore in uno dei nodi, poiché l'altro nodo può occuparsi di tutto il traffico, magari influendo leggermente sulle prestazioni, ma senza mai perdere la funzionalità. Viene anche utilizzato per realizzare (e forse questo è un punto ancora più interessante) la scalabilità orizzontale (scale-out), opposta al concetto di scalabilità verticale in cui aggiungiamo più risorse a un server (scale-up).
Per implementare questa architettura, dovrai utilizzare strumenti esterni, poiché questa funzionalità non è (ancora) supportata nativamente da PostgreSQL.
È necessario prestare molta attenzione quando si sceglie una soluzione per l'implementazione di master-master, poiché esistono molti prodotti diversi. Molti di loro sono ancora "verdi", con pochi utenti seri o casi di successo. Alcuni altri progetti, invece, sono stati abbandonati, in quanto non ci sono manutentori attivi.
Per ulteriori informazioni sugli strumenti disponibili, fare riferimento a:Blog:Top PG Clustering HA Solutions for PostgreSQL.
Bilanciamento del carico e pool di connessioni
Esistono diversi strumenti di bilanciamento del carico che possono essere utilizzati per gestire il traffico dall'applicazione per ottenere il massimo dall'architettura del database. Allo stesso modo, ce ne sono altri che possono aiutarti a gestire il modo in cui l'applicazione si connette al database, mettendo in comune queste connessioni e riutilizzandole tra diverse richieste.
Ci sono alcuni prodotti che vengono utilizzati per entrambi gli scopi, come il noto pgpool, e altri che si concentreranno solo su una di queste funzionalità, come pgbouncer (pooling di connessioni) e HAProxy (usato per il bilanciamento del carico).
