Finora abbiamo trattato esclusivamente il tema del server MySQL visto in ottica di istanza singola, quindi con un'installazione limitata ad una sola macchina. Benché questa sia la configurazione più utilizzata in ambito web visto che la quasi totalità dei servizi di hosting offre questa possibilità, soprattutto in ambiente business è cresciuta sempre di più la necessità di utilizzare sistemi distribuiti.
In questo modo, tramite una configurazione più o meno complessa, diverse macchine cooperano seguendo certi schemi di funzionamento al fine di ottenere risultati che possono essere:
- aumento delle prestazioni, soprattutto in lettura;
- load balancing (bilanciamento di carico), con la possibilità di incrementare le prestazioni complessive per ridurre il carico su una singola macchina;
- duplicazione dei dati, utile in caso di disaster recovery poichè mantiene una sorta di backup live;
- distribuzione geografica, che riduce i tempi di connessione avvicinando una copia del server al client;
- high availability (HA), cioè alta disponibilità del servizio per cercare di ottenere un aumento dell'affidabilità riducendo al minimo i tempi in cui il servizio rimane offline, anche in caso di danni ad una macchina.
Benché queste necessità siano nate in ambito business, con lo sviluppo enorme a cui abbiamo assistito negli ultimi anni nelle soluzioni Cloud e VPS (Virtual Private Server) sono diventate una realtà alla portata anche di budget ridotti: con tre VPS da 1 GB di RAM è infatti possibile costruire il proprio cluster per HA in modo semplice ed ottenendo comunque un buon livello di prestazioni.
Replicazione master/slave
Con questa configurazione abbiamo un server principale, il master, che viene utilizzato per le operazioni di scrittura e dei server secondari, gli slave, che possono essere in numero variabile con un minimo di uno. I server slave non possono effettuare operazioni di scrittura; o meglio, potrebbero farlo ma ciò pottrebbe compromettere la replicazione dei dati. Rispetto ad altri software che presentano questa caratteristica, MySQL ha una forte limitazione: i server slave non possono prendere il posto del master nel momento in cui questo viene meno. Ciò significa che in questa configurazione abbiamo un punto di fallimento singolo: se il server principale si guasta, si spegne o va in errore, non sarà possibile eseguire ulteriori operazioni in scrittura e sarà necessario un intervento manuale.
In sostanza quindi abbiamo un server principale disponibile in lettura e scrittura e dei server secondari disponibili in sola lettura che vengono autoaggiornati dal server principale ad ogni modifica intervenuta. Ovviamente trattandosi esclusivamente di una questione di configurazione ad un certo punto potremmo decidere di trasformare una macchina slave in master. MySQL ci permette anche di limitare la replica solo ad alcuni database presenti sulla macchina principale.
Replicazione master/master
Questa configurazione assomiglia alla precedente ma le macchine in gioco sono solo due. In sostanza ogni istanza diventa contemporaneamente master e slave dell'altra, quindi qualsiasi operazione in scrittura su una delle due macchine sarà replicata sull'altra. In questo modo, anche se una macchina cade è possibile continuare ad operare sia in lettura che in scrittura senza un intervento manuale.
A prima vista questa configurazione potrebbe sembrare fantastica ma comporta una serie di problemi tecnici non indifferenti come il brain split per cui in caso di interruzione del collegamento tra le due macchine potrebbero essere state effettuate modifiche su entrambe che così facendo non potrebbero riprendere la replicazione al ripristino della connessione. Questo problema è il punto debole di tutta la teoria del clustering, vale per qualsiasi tecnologia ma il suo impatto pratico può variare in base all'implementazione pratica dei sistemi.
Il vantaggio principale di questo tipo di replicazione risiede nell'HA, anche se è limitato a due macchine. Si tenga presente, infine, che all'aumentare della distanza fisica tra i due server aumenta la possibilità di un'interruzione della replicazione per inserimenti concorrenziali incompatibili. Anche in questo caso è possibile ovviare al problema tramite una progettazione idonea del sistema nel complesso.
Cluster tramite Storage Engine NDB
MySQL supporta lo Storage Engine NDB, pensato appositamente per la creazione di cluster. Il punto debole di questo sistema è sicuramente dato dall'estrema complessità e dall'elevato numero di macchine necessarie per poterlo implementare.
L'architettura prevede infatti la necessità di avere almeno tre tipi di macchine:
- data node, cioè i server che ospiteranno fisicamente i dati (in ottica cluster dovrebbero essere per lo meno tre per evitare il brain split);
- SQL nodes, cioè i server MySQL che si interfacceranno con i data node ed offriranno i propri servizi ai vari client (almeno una macchina);
- NDB Management Server, cioè il server che si occuperà di coordinare le attività dei data node.
A causa di un processo di configurazione abbastanza macchinoso, questa soluzione non ha riscosso grande successo.
Cluster tramite Galera
Galera permette ad un insieme di server MySQL di cooperare tra di loro in un'architettura di tipo multi-master in maniera analoga a quanto avviene con le replicazioni master/master, ma permettendo un numero maggiore di server.
In questo modo è possibile configurare il numero magico di tre server che permettono di evitare il problema dello split brain ed ottenere un sistema HA. La configurazione è abbastanza semplice anche se la distanza fisica tra i server può compromettere le prestazioni del cluster e addirittura rischiare la fuoriuscita di alcune macchine dallo stesso. Vedremo come ovviare a questo genere di problemi nell'approfondimento dedicato a questa promettente tecnologia che oggi viene considerata la principale scelta nel clustering MySQL.