Cluster con Galera

Come abbiamo visto, MySQL permette di impostare una replica multimaster che permette di mimare il funzionamento di un cluster di server. Per ottenere questo comportamento, è necessario in realtà configurare una serie di server, minimo due, perché ognuno sia slave del precedente e master del successivo, formando una configurazione ad anello.

Questa soluzione effettivamente funziona, ma come si può intuire è in realtà un workaround con alcuni problemi pratici: ad esempio, un anello di server master in replica non è in grado di tollerare alcun tipo di malfunzionamento, neanche temporaneo, di uno dei server implicati (in termini tecnici non è garantita una fault tolerance e ognuno dei server rappresenta un point of failure).

Nel caso in cui uno dei server smettesse di funzionare, per un problema hardware, un'interruzione del collegamento, semplice manutenzione o qualsiasi altro motivo, la continuità dell'anello non sarebbe più garantita e questo potrebbe portare alla perdita irreversibile dei dati sui server a valle dell'interruzione, e comunque la mancata sincronizzazione. Il sistema sarebbe quindi inconsistente, con i vari server che presentano set differenti di dati, cioè l'esatto contrario dell'obiettivo minimo che un cluster deve raggiungere.

Utilità di un cluster di server in MySQL

Per risolvere questo problema strutturale è necessario passare ad un cluster vero e proprio, con tutti i pro e i contro che questo comporta. Tra i vantaggi, da notare sicuramente la ridondanza, la gestione del failover e della tolleranza del fallimento, la scalabilità futura.

Di contro, un cluster vero e proprio richiede un numero dispari di server per evitare il fenomeno dello split brain, e quindi non meno di tre server; inoltre, esso ha bissogno di un sistema di monitoraggio continuo e, in termini generali, ha un livello di complessità superiore che si traduce in un complesso insieme di opzioni di configurazione (anche se è possibile in generale utilizzare le opzioni di default per semplificare questa fase).

Anche per i cluster valgono le stesse limitazioni delle repliche master/master, come il rischio di conflitto tra indici primari, ma sicuramente il gioco vale la candela, considerando anche che esistono delle contromisure per poter prevenire queste criticità.

MySQL supporta nativamente un sistema di clustering tramite lo storage engine NDB: questo comporta, però, alcuni svantaggi, come l'impossibilità di scegliere uno storage engine differente e sfruttare di conseguenza le caratteristiche di quest'ultimo. Ad esempio, con questa soluzione non è possibile sfruttare le prestazioni di una tabella MyISAM o le funzionalità avanzate delle tabelle InnoDB.

Galera

Una scelta più semplice consiste nell'utilizzo del software Galera, una soluzione inizialmente pensata per MySQL e che oggi invece supporta anche PerconaDB e MariaDB. Trattandosi di un software extra, sarebbe necessaria un'installazione e configurazione aggiuntiva rispetto al semplice server MySQL, ma oggi praticamente tutti i gestori di pacchetti per Linux e Windows permettono l'installazione diretta di Galera.

Galera nasce come fork di InnoDB, con in più una modifica dei meccanismi di replica visti fino ad ora. Oggi è un sistema completo che supporta una gestione automatizzata dei server da aggiungere al cluster e la replica atomica record per record. Esiste la possibilità di impostare il cluster per agire a livello di WAN, cioè su una rete geograficamente molto ampia, per poter ad esempio distribuire i server in modo da migliorare le prestazioni in lettura di un'applicativo/sito web con utenza presente in varie località distanti.

Uno dei vantaggi più importanti consiste nella gestione automatizzata degli aggiornamenti dei record tra server del cluster: ogni volta che si aggiunge un server al cluster (operazione cosiddetta di join), il sistema si occupa autonomamente di copiarvi i dati da uno dei server già presenti nel cluster. Questo evita l'inconsistenza dei dati e permette agevolmente di rimuovere un server dal cluster, eseguire la manutenzione necessaria e riaggiungere il server al cluster senza la necessità di copiare manualmente i dati.

Tecnicamente, un cluster di questo tipo funziona a grandi linee in questa maniera:

• su una tabella transazionale (ad esempio InnoDB) vengono applicate delle modifiche che, esplicitamente o implicitamente, vengono inserite all'interno di transazioni;
• il server assegna un identificativo alla transazione;
• le API wsrep si accorgono della modifica e notificano agli altri server del cluster le transazioni da eseguire per riportarsi in linea;
• le modifiche vengono applicate e il cluster ritorna in uno stato di sincronizzazione.

Configurazione base di Galera

Dopo questo excursus teorico, vediamo in concreto cosa è necessario fare per poter configurare e avviare un cluster con Galera. Innanzitutto, dobbiamo impostare il primo nodo, che darà l'avvio al cluster. Quindi fermiamo l'esecuzione di MySQL tramite il comando specifico per il sistema operativo, ad esempio sudo service mysql stop sui sistemi Debian/Ubuntu.

Nel file di configurazione my.cnf è necessario impostare una serie di parametri generici per poter ottenere un server compatibile con Galera. La replica infatti avviene a livello di record e non di tabella e Galera supporta esclusivamente storage engine di tipo transazionale (come InnoDB). Questi parametri sono fissi e possono essere copiati così come sono nella sezione [mysqld]:

[mysqld]
# ...
binlog_format            = ROW
default-storage-engine   = innodb
innodb_autoinc_lock_mode = 2

A questo punto è necessario impostare i parametri relativi alle wsrep API, cioè l'interfaccia utilizzata da Galera per la notifica delle modifiche al database. Quindi, sempre nella sezione [mysqld], impostiamo quanto segue:

[mysqld]
# ...
wsrep_on       = ON
wsrep_provider = /usr/lib/galera/libgalera_smm.so
wsrep_cluster_name    = "nome_del_cluster"
wsrep_cluster_address = "gcomm://1.1.1.1,2.2.2.2,3.3.3.3"
wsrep_sst_method      = rsync
wsrep_node_address    = "1.1.1.1"
wsrep_node_name       = "nome_del_nodo"

La prima riga attiva le API wsrep e quindi il cluster, mentre la seconda è il path del plugin Galera (il valore indicato è il default sui sistemi linux). wsrep_sst_method indica il metodo per il trasferimento dei dati al momento del join di un server al cluster, non viene quindi utilizzato per gli aggiornamenti successivi ad uno stato di sincronizzazione dello stesso. Il valore indicato è quello più comune e permette il funzionamento out of the box del cluster.

Gli altri parametri, invece, sono specifici del cluster, per cui è necessario sostituire nome_del_cluster con una stringa che identifichi il cluster. L'importante è che la stessa stringa sia presente nella configurazione di ogni macchina dello stesso cluster. Nell'opzione wsrep_cluster_address devono essere impostati gli IP dei server che ne fanno parte (in realtà non è necessario elencarli tutti: l'importante è che almeno uno sia raggiungibile - per permettere al nodo di ricollegarsi al cluster al momento del riavvio della macchina o di MySQL, oppure dopo uno stato di inconsistenza risolto).

Per finire, è necessario impostare le opzioni di configurazione specifiche per la singola macchina. A tal fine, in wsrep_node_address va indicato l'IP pubblico del server, e in wsrep_node_name una stringa identificativa della macchina (l'importante in questo caso è che la stringa sia diversa per ogni server del cluster).

A questo punto rimane da avviare il cluster passando il parametro --wsrep-new-cluster al demone MySQL:

sudo /etc/init.d/mysql start --wsrep-new-cluster

Questo non è il sistema di default per avviare MySQL, e deve essere utilizzato solo all'avvio del cluster, quando non è presente nessuna altra macchina all'interno dello stesso.

I nodi aggiuntivi

Nei file di configurazione delle altre macchine del cluster, copiamo tutte le opzioni di configurazione che abbiamo impostato sul server primario, modificando solo wsrep_node_address e wsrep_node_name. Quindi avviamo uno ad uno i server MySQL con il sistema standard; ad esempio:

sudo service mysql start

Il server a questo punto esegue le seguenti azioni:

• si avvia a livello software ed avvia le API wsrep;
• cerca nell'elenco degli indirizzi IP forniti nell'opzione di configurazione wsrep_cluster_address almeno un server valido già avviato e presente nel cluster;
• richiede a questo server lo stato;
• aggiorna il proprio recordset per portarsi in pari;
• viene impostato come attivo e sincronizzato nel cluster per altri nodi che richiedono di connettersi.

Avviati ulteriori nodi, è possibile fermare l'esecuzione del demone MySQL sul server primario e riavviarlo con il comando standard, garantendo comunque il collegamento al cluster. Con queste semplici operazioni abbiamo avviato un cluster di server MySQL garantendo l'HA (alta disponibilità), la ridondanza dei dati, il failover, oltre alla possibilità di aggiungere ulteriori server al bisogno.