Documentazione di PostgreSQL 9.0 > Amministrazione del server > Alta disponibilità, bilanciamento di carico e replica
PrecedenteMigrazioni fra versioniLog-Shipping Standby ServersSuccessivo

25. Alta disponibilità, bilanciamento di carico e replica

I server database possono lavorare insieme per permettere ad un secondo server di prenderne il posto se il server primario fallisce (alta disponibilità), o per permettere a diversi computer di servire gli stessi dati (bilanciamento di carico). Idealmente, i server database potrebbero lavorare insieme ininterrottamente. I server web che servono pagine web statiche possono essere combinati abbastanza facilmente semplicemente bilanciando le richieste web su molteplici macchine. Infatti, server database in sola lettura possono essere combinati in maniera relativamente semplice. Sfortunatamente, la maggior parte dei server database hanno un insieme di richieste di lettura e scrittura, e i server in lettura/scrittura sono molto difficili da combinare. Questo perchè sebbene i dati in sola lettura devono essere posizionati su ogni server solo una volta, una scrittura ad un qualsiasi server deve essere propagata a tutti i server così che le letture future su quei server ritornino risultati consistenti.

Questo problema di sincronizzazione è la difficoltà fondamentale perchè i server lavorino insieme. Dato che non c'è una singola soluzione che elimina l'impatto del problema di sincronizzazione per tutti i casi d'uso, ci sono diverse possibilità. Ogni soluzione indirizza questo problema in modo differente, e minimizza il suo impatto per un carico di lavoro specifico.

Alcune soluzioni realizzano la sincronizzazione permettendo solo ad un server di modificare i dati. I server che possono modificare i dati vengono chiamati server read/write, master o primary. I server che tengono traccia dei cambiamenti nel master vengono chiamati standby o server slave. Un server standby a cui non ci si può connettere finchè non viene promosso a server master viene chiamato server warm standby, ed uno che può accettare connessioni e servire query in sola lettura viene chiamato server hot standby.

Alcune soluzioni sono sincrone, che significa che una transazione che non modifica i dati non si considera sottoposta a commit finchè tutti i server non hanno fatto il commit della transazione. Questo garantisce un failover che non perderà nessun dato e i server con bilanciamento di carico restituiranno risultati consistenti qualsiasi server verrà interrogato. Al contrario, soluzioni asincrone permettono un po' di ritardo tra il momento di una commit e la sua propagazione agli altri server, aprendo la possibilità che alcune transazioni potrebbero essere perse nel passaggio a un server di backup, e che i server con carico bilanciatio potrebbero ritornare risultati leggermenti non aggiornati. La comunicazione asincrona viene usata quando quella sincrona sarebbe troppo lenta.

Le soluzioni possono anche essere categorizzate dalla loro granularità. Alcune soluzioni possono trattare un intero server di database, mentre altre permettono di avere un controllo a livello di tabella o di singolo database.

Le prestazioni devono essere tenute in considerazione prima di prendere qualsiasi decisione. Di solito c'è un trade-off tra le funzionalità e le prestazioni. Per esempio, una soluzione completamente sincrona su una rete lenta potrebbe far diminuire le prestazioni di più della metà, mentre una asincrona potrebbe avere un impatto minimo sulle prestazioni.

Il promemoria di questa sezione evidenzia diverse soluzioni di failover, replica, e bilanciamento di carico. Anche un glossario è disponibile.

25.1. Confronto di diverse solutioni

Shared Disk Failover

Shared disk failover evita l'overhead di sincronizzazione avendo una sola copia del database. Usa un singolo array di disco che è condiviso da molteplici server. Se il server database principale fallisce, il server standby è capace di montare e avviare il database sebbene stesse recuperando da un crash. Questo permette un failover rapido senza perdita di dati.

Shared hardware functionality is common in network storage devices. Using a network file system is also possible, though care must be taken that the file system has full POSIX behavior (see Sezione 17.2.1, «Network File System»). Una limitazione significativa di questo metodo è che se l'array di disco condiviso fallisce o si corrompe, i server primario e standby diventano entrambi non funzionanti. Un'altra questione è che il server standby non accede mai l'immagazzinamento condiviso mentre il server primario è in esecuzione.

File System (Block-Device) Replication

A modified version of shared hardware functionality is file system replication, where all changes to a file system are mirrored to a file system residing on another computer. La sola restrizione è che il mirroring deve essere fatto in modo da assicurare che il server standby abbia una copia consistente del file system - nello specifico, le scritture sullo standby devono essere fatte nello stesso ordine di quelle sul master. DRBD™ è una soluzione popolare di replica con file system per Linux.

Warm and Hot Standby Using Point-In-Time Recovery (PITR)

I server warm e hot standby possono essere tenuti aggiornati leggendo uno stream di record di log write-ahead (WAL). Se il server principale fallisce, lo standby contiene praticamente tutti i dati del server principale, e può essere reso velocemente il nuovo server database master. Quest'operazione è asincrona e può essere fatta solo per l'intero server database.

Un server stanby PITR può essere implementato usando il log shipping basato sui file (Sezione 25.2, «Log-Shipping Standby Servers») o la replica streaming (si veda Sezione 25.2.5, «Replica streaming»), o una combinazione di entrambi. Per informazioni su hot standby, si veda Sezione 25.5, «Hot Standby».

Replica master-slave basata sui trigger

Un sistema di replica master-standby manda tutte le query che modificano i dati al server master. Il server master manda in modo asincrono i cambiamenti dei dati al server standby. Lo standby può rispondere con query in sola lettura mentre il server master è in esecuzione. Il server standby è ideale per query di data warehouse.

Slony-I™ è un esempio di questo tipo di replica, con granularità a livello di tabella, e supporto per molti server standby. Dato che aggiorna il server standby in modo asincrono, c'è una possibile perdita di dati durante il fail over.

Statement-Based Replication Middleware

With statement-based replication middleware, a program intercepts every SQL query and sends it to one or all servers. Each server operates independently. Read-write queries are sent to all servers, while read-only queries can be sent to just one server, allowing the read workload to be distributed.

If queries are simply broadcast unmodified, functions like random(), CURRENT_TIMESTAMP, and sequences can have different values on different servers. This is because each server operates independently, and because SQL queries are broadcast (and not actual modified rows). If this is unacceptable, either the middleware or the application must query such values from a single server and then use those values in write queries. Another option is to use this replication option with a traditional master-standby setup, i.e. data modification queries are sent only to the master and are propagated to the standby servers via master-standby replication, not by the replication middleware. Care must also be taken that all transactions either commit or abort on all servers, perhaps using two-phase commit (PREPARE TRANSACTION(7) and COMMIT PREPARED(7). Pgpool-II™ and Sequoia™ are examples of this type of replication.

Replica multimaster asincrona

Per server che non sono connessi regolarmente, come portatili o server remoti, mantenere la consistenza dei dati tra i server è una sfida. Usando la replica multimaster asincrona, ogni server funziona indipendentemente, e comunica periodicamente con gli altri server per identificare transazioni che sono in conflittto. I conflitti possono essere risolti da utenti o da regole di risoluzione dei conflitti. Bucardo è un esempio di questo tipo di replica.

Replica multimaster sincrona

Nella replica multimaster sincrona, ogni server può accettare richieste di scrittura, e i dati modificati vengono trasmessi dal server originale ad ogni altro server prima di ogni commit di transazione. Attività di scrittura pesante può causare un'eccessiva attività di locking, generando prestazioni scarse. Infatti, le prestazioni di scrittura spesso sono peggiori rispetto a quelle di un singolo server. Le richieste di lettura possono essere mandate a qualsiasi server. Alcune implementazioni usano dischi condivisi per ridurre l'overhead di comunicazione. La replica multimaster sincrona è la migliore per carichi di lavoro che sono per la maggior parte in lettura, sebbene il suo maggior vantaggio è che qualsiasi server accetta rischieste di scrittura - non c'è bisogno di partizionale i carichi di lavoro tra i server master e standby, e dato che i cambiamenti dei dati vengono mandati da un server all'altro, non c'è problema con funzioni non deterministiche come random().

PostgreSQL™ non offre questo tipo di replica, sebbene la commit a due fasi (PREPARE TRANSACTION(7) e COMMIT PREPARED(7)) può essere usata per implementarlo nel codice dell'applicazione.

Soluzioni commerciali

Dato che PostgreSQL™ è open source e facilmente estendibile, un certo numero di compagnie hanno usato PostgreSQL™ e creato soluzioni commerciali non open source con capacità di failover, replica e bilanciamento di carico particolari.

Tabella 25.1, «Matrice delle caratteristice di alta disponibilità, bilanciamento di carico e replica» riassume le capacità delle varie soluzioni elencate sopra.

Tabella 25.1. Matrice delle caratteristice di alta disponibilità, bilanciamento di carico e replica

FeatureShared Disk FailoverFile System ReplicationHot/Warm Standby Using PITRTrigger-Based Master-Standby ReplicationStatement-Based Replication MiddlewareAsynchronous Multimaster ReplicationSynchronous Multimaster Replication
Most Common ImplementationNASDRBDPITRSlonypgpool-IIBucardo 
Communication Methodshared diskdisk blocksWALtable rowsSQLtable rowstable rows and row locks
No special hardware required 
Allows multiple master servers    
No master server overhead    
No waiting for multiple servers   
Master failure will never lose data   
Standby accept read-only queries  Hot only
Per-table granularity    
No conflict resolution necessary  

Ci sono alcune soluzioni che non appartengono alle categorie sopra:

Partizionamento dei dati

Il partizionamento dei dati divide le tabelle in insiemi di dati. Ogni insieme può essere modificato solamente da un server. Per esempio, i dati possono essere partizionati per uffici, per esempio Londra e Parigi, con un server in ogni ufficio. Se le query che combinano i dati di Londra e Parigi sono necessarie, un'applicazione può interrogare entrambi i server, o è possibile usare la replica master/standby per mantenere una copia in sola lettura dei dati dell'altro ufficio su ogni server.

Esecuzione parallela di query su più server

Molte delle soluzioni presentate sopra permettono la gestione di molte query da parte di molti server, ma nessuna permette che una singola query usi molteplici server per terminare più velocemente. Questa soluzione permette a molti server di funzionare concorrentemente su una singola query. Di solito questo di ottiene dividendo i dati tra i server e facendo si che ogni server esegua la sua parte della query e restituisca i risultati al server centrale dove saranno combinati e restituiti all'utente. Pgpool-II™ ha questa capacità. Inoltre, questo comportamento può essere implementato usando l'insieme di strumenti PL/Proxy™.

Documentazione di PostgreSQL 9.0 > Amministrazione del server > Alta disponibilità, bilanciamento di carico e replica
PrecedenteMigrazioni fra versioniLog-Shipping Standby ServersSuccessivo