MariaDB e MariaDB Cluster: i Vantaggi

Maria DB e Maria DB Galera Cluster cosa sono? Cerchiamo di fare chiarezza...

Partiamo dalle definizioni: Maria DB è un sistema di gestione di database relazionali (RDBMS) mentre MariaDB Cluster è un cluster sincrono per i database MariaDB multi master.

Perché usare Galera Cluster?

Le funzionalità di cui si può usufruire sono molteplici, come per esempio l’unione dei nodi automatica e la replica sincrona, ma anche le connessioni dirette dei clienti: vale la pena di citare, inoltre, la topologia multi master active active e la vera replica parallela a livello di riga.

Il progetto MariaDB si focalizza sulla messa a punto di MariaDB Cluster con la collaborazione di Codership; allo stato attuale viene ritenuto di qualità Alpha, fermo restando che viene impiegato da numerosi utenti con risultati più che apprezzabili.

La disponibilità elevata e il funzionamento costante rappresentano, per le soluzioni di gestione dei database più all’avanguardia, degli elementi di fondamentale importanza, al pari delle opzioni di scalabilità flessibili.

Si tratta di esigenze da cui non si può prescindere per poter soddisfare le necessità contemporanee, con accessi fortemente oscillanti e, spesso, picchi di carico molto più alti del previsto. Lo scopo è assecondare tali requisiti a dispetto di un budget piccolo per i costi di infrastruttura.

È a questo che serve Galera Cluster, che costituisce una soluzione eccellente in tal senso: si tratta, come si è detto, di una soluzione di clustering multimaster destinata ai database che si fonda sulla replica sincrona a prestazioni elevate.

In questo modo tutti i nodi che fanno parte di una rete di banche dati hanno la possibilità di ricevere in tempo reale gli stessi dati.

Galera Cluster, che è disponibile per MariaDB ma non solo, assicura i più alti standard di affidabilità e una perdita di dati minima.

Quali sono i requisiti di memoria di Galera Cluster?

Nel corso delle operazioni normali, il consumo di memoria di un nodo MariaDB Galera è paragonabile più o meno a quello di un normale server MariaDB. Cresce il consumo per gli insiemi di modifiche e l’indice della certificazione, fermo restando che in genere una tipica applicazione non si dovrebbe rendere conto della differenza.

Nel momento in cui un trasferimento di stato viene ricevuto da un nodo, però, questo non può né elaborare né applicare gli insiemi di modifiche in ingresso, dal momento che non è disponibile uno stato su cui esse possano essere applicate. In base al meccanismo di trasferimento, inoltre, potrebbe essere che gli insiemi di modifiche non risultino applicabili nemmeno dal nodo che lo trasmette.

Proprio per questo motivo c’è bisogno di scrivere le modifiche in una cache, così che in seguito si possa fare catch-up. Adesso gli insiemi di modifiche sono scritti in una cache. Nel caso in cui l’intera memoria a disposizione venga consumata dal sistema, può succedere che il trasferimento di stato non vada a buon fine o che il cluster si concluda in attesa che termini il trasferimento.

Cos'è il pacchetto software Galera Cluster?

MariaDB Galera Cluster è un pacchetto software grazie a cui è possibile realizzare e gestire cluster MariaDB, ma anche XtraDB e MySQL, per sistemi operativi Linux.

Lo storage engine InnoDB rappresenta la base dell’applicazione cluster. Il motore MylSAM, a sua volta, è supportato in maniera sperimentare, ed è stato impiegato come predecessore di InnoDB con MariaDB e MySQL per molto tempo. In virtù di questo pacchetto software, il principio della replica sincrona viene implementato nella memorizzazione dei dati nei diversi nodi di cluster indipendenti.

Si eseguono nello stesso momento sia i processi di copia che le modifiche ai dati che sono stati memorizzati sia sulle unità di memorizzazione primarie che sulle unità di memorizzazione secondarie, affinché i dati dei vari nodi siano aggiornati in continuazione e non vi siano differenze.

Un cluster di base è formato da tre nodi, e in ogni caso, gli sviluppatori suggeriscono che il numero sia dispari.

Nell’ipotesi in cui un nodo si dovesse bloccare mentre la transazione dei dati è in corso, magari per un difetto del sistema o per colpa di problemi di rete, bastano comunque gli altri due nodi che consentono alla transazione di concludersi senza problemi.

Le caratteristiche principali del cluster MariaDB che usa Galera Cluster

La peculiarità di un cluster MariaDB fondato su Galera Cluster riguarda il fatto che i vari nodi della rete hanno a disposizione dati sempre uguali.

Con il software cluster non è più prevista la tradizionale distinzione fra slave e master, vale a dire server di sola lettura e server scrivibili, che caratterizza i server di database. Di conseguenza gli utenti hanno l’opportunità di scrivere dati su qualunque nodo di archiviazione.

Dopodiché i dati in automatico sono inoltrati agli altri partecipanti. Tale proprietà viene indicata con il nome di multi master.

Configurare un cluster Galera di base

I tre nodi di un cluster Galera di base eseguono ciascuno MariaDB con alcuni parametri aggiuntivi in /etc/mysql/mariadb.conf.d/50-server.cnf (o galera.cnf, a seconda della distribuzione). I parametri principali che trasformano un'istanza MariaDB standalone in un nodo di cluster sono:

[galera]
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_address="gcomm://ip_nodo1,ip_nodo2,ip_nodo3"
wsrep_cluster_name="cluster_produzione"
wsrep_sst_method=mariabackup
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2

Il primo nodo viene avviato da solo (gcomm:// senza indirizzi, oppure con il comando galera_new_cluster fornito dalla distribuzione), dopodiché gli altri due si uniscono puntando all'indirizzo di cluster indicato sopra; su un cluster già attivo, riavviare un nodo comporta semplicemente una richiesta di State Snapshot Transfer (SST) a un nodo esistente per allinearsi.

Gli errori che si incontrano davvero

• Un nodo non entra nel cluster e resta in stato "Initialized" o "Joining" — di solito è in corso un State Snapshot Transfer (SST) completo, che su un database di dimensioni reali può richiedere da pochi minuti ad alcune ore; conviene controllare il log di errore del nodo donatore invece di dare per scontato che il nodo in ingresso sia rotto.
• wsrep_sst_method fallisce a metà — mariabackup (il metodo predefinito nelle versioni recenti) richiede accesso in scrittura alla directory dati del nodo in ingresso e spazio disco sufficiente per una copia completa del dataset; esaurire lo spazio disco a metà trasferimento è la causa più comune di un SST bloccato o fallito.
• Il cluster resta bloccato in stato "non-Primary" dopo uno split di rete — Galera usa il quorum (maggioranza stretta dei nodi) per decidere quale lato di una partizione di rete può continuare ad accettare scritture; con soli due nodi non c'è modo di rompere un pareggio, ed è proprio per questo che tre nodi (o comunque un numero dispari) sono il minimo consigliato, non un semplice suggerimento.
• Un nodo viene espulso ripetutamente dal cluster — spesso è un problema di latenza di rete o di firewall tra i nodi, non un problema di MariaDB: la replica di Galera è sincrona, quindi un collegamento costantemente lento tra due sedi si adatta male a questo tipo di architettura (un cluster "stirato" tra due uffici, su VPN, è uno dei motivi più frequenti di instabilità che si incontrano in pratica).

Come si fa il backup di un cluster Galera

Dato che ogni nodo contiene dati identici, in linea di principio il backup può essere eseguito da un qualsiasi nodo con mariabackup (lo stesso strumento usato per l'SST) oppure con lo stesso approccio mysqldump usato per un server MariaDB standalone. In pratica conviene destinare un nodo specifico ai job di backup e, dove possibile, eseguirli su un nodo temporaneamente desincronizzato dal cluster (SET GLOBAL wsrep_desync=ON) per evitare che il carico I/O del backup influisca sulle prestazioni di scrittura del resto del cluster.

Quando Galera Cluster è (e non è) la scelta giusta

Un cluster sincrono multi-master risolve un problema reale — nessun single point of failure, e ogni nodo può accettare scritture — ma ha un costo in termini di latenza di scrittura (ogni commit deve essere certificato su tutti i nodi) e di complessità operativa reale: tre server da aggiornare e monitorare invece di uno, e un rischio concreto di SST bloccato o di split del quorum se la rete sottostante non è solida. Per un'azienda che gestisce una singola applicazione su un database che può tollerare qualche minuto di downtime e un ripristino da backup, una normale istanza MariaDB con backup regolari resta di solito la scelta più semplice e sostenibile nel tempo. Galera giustifica la sua complessità quando il database stesso non può essere un punto singolo di guasto — per esempio dietro un servizio rivolto ai clienti che deve restare raggiungibile anche mentre un server viene aggiornato o è fuori uso.

La soluzione a portata di click!

Non sai come utilizzare in maniera corretta MariaDB Cluster o hai avuto dei problemi con la sua fruizione? Contattaci: il team di TN Solutions è pronto a offrirti tutta l’assistenza che ti serve per ogni esigenza nel settore informatico.