MySQL Galera Cluster

Galera Cluster for MySQL e' un cluster multimaster basato sulla replicazione sincrona.
Per la sua efficienza e scalabilita' sta trovando una sempre maggior diffusione. Gli utilizzi piu' comuni sono per l'implementazione di soluzioni in alta affidabilita' e nelle configurazioni in Cloud.

Nel seguito sono riportate alcune informazioni di interesse organizzate in paragrafi specifici: Introduzione, Architettura, Installazione e configurazione, Avvertenze per l'uso, Amministrazione (FAQ), Galera vs NDB, Galera vs Replication, Galera vs Group Replication, ...

Il contenuto di questo documento e' tecnico. E' opportuna una conoscenza dell'architettura MySQL, degli storage Engine e della Replication.

Introduzione

Galera Cluster for MySQL e' un cluster multimaster basato sulla replicazione sincrona tra nodi in configurazione shared nothing.

I client si collegano ai database MySQL esattamente come se fossero nodi standalone.
I nodi di un cluster Galera sono connessi tra loro in configurazione N-N e dialogano mediante l'API wsrep (write set replication API). Vengono gestiti dal cluster i tipici eventi di ingresso/uscita dei nodi dal cluster, il trasferimento iniziale dei dati, le situazioni di split-brain, ... Mentre ciascun nodo si occupa localmente di gestire le connessioni con i client, eseguire le query SQL in modo efficiente, ...
I nodi vengono mantenuti sempre sincronizzati tra loro replicando le transazioni al momento del commit. La fase di verifica della transazione viene chiamata certification test. Se il risultato e' positivo la transazione viene trasferita (writeset) ed eseguita su tutti i nodi del cluster nello stesso ordine. Se il certification test fallisce la transazione viene abortita e l'applicazione dovra' risottometterla.
L'algorimo utilizzato da Galera e' di tipo ottimistico ed utilizza una tecnica di ordinamento delle transazioni per ridurre il numero di abort.

I vantaggi di Galera sono:

• HA
  Le transazioni confermate non vengono perse anche nel caso di crash.
• Few Application Changes
  Le applicazioni utilizzano il cluster come se si trattasse di un normale database MySQL singolo.
• Multi-Master
  Tutti i nodi sono paritetici ed effettuano le modifiche sulla stessa tabella in modo concorrente.
• Scalability
  La soluzione e' scalabile anche per applicazioni con un numero elevato di DML.
• No specialized hardware
  I nodi non utilizzano dischi shared ma operano sullo storage locale, non sono implementate complesse cache globali, non sono richieste interfacce di rete dedicate per l'heartbeat, ...

Architettura

Le applicazioni client si collegano ad uno qualsiasi dei nodi del cluster che si comporta come un database standalone. Le attivita' di lettura vengono eseguite localmente e cosi' avviene per le istruzioni di DML fino al momento del commit. In fase di commit il cluster verifica (certification test) se l'operazione puo' essere eseguita senza conflitti. Per fare questo la transazione viene impacchettata (write-set), inviata su tutti i nodi, confermata (certification-test) ed eseguita (commit). Le transazioni vengono effettuate nello stesso ordine su tutti i nodi che risultano quindi sincronizzati. Questo approccio e' definito virtually synchronous replication nel senso che i nodi applicano gli stessi write-set nello stesso ordine ma in realta' le scritture e le commit sono demandate ai DB locali ed avvengono in modo asincrono.

Per mantenere l'allineamento dei dati i nodi comunicano tra loro; oltre alla porta 3306, che e' il default di accesso ai database, i nodi utilizzano la porta 4567 per il traffico di replica (TCP per l'unicast, TCP ed UDP per il multicast), la porta 4568 per l'IST e la porta 4444 per l'SST.
Anche se le API wsrep (write set replication API) sono teoricamente implementabili su un qualsiasi RDBMS, l'implementazione disponibile di Galera e' quella per l'Engine InnoDB di MySQL. Solo le attivita' sull'Engine InnoDB vengono replicate, gli altri Engine operano localmente ed e' in generale opportuno evitarne l'utilizzo.
Le applicazioni non debbono subire particolari modifiche ma solo trattare l'eventuale errore sulla commit. Infatti se la transazione non puo' essere eseguita il client riceve l'errore 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK) e viene effettuato il rollback di tutti i dati.

Dal punto di vista tecnico Galera Cluster for MySQL e' costituito da una versione MySQL con una patch che utilizza le API wsrep e dal provider Galera che e' implementato come demone garbd.

Installazione e configurazione

Questa pagina fa riferimento all'installazione di MySQL 5.6.21 con la patch wsrep 25.9 e Galera 3-25.3.9 su CentOS 6.x ma quanto riportato vale anche con poche differenze anche per le altre versioni.

L'installazione richiede il download di due componenti:

• MySQL con wsrep patch
• Galera wsrep provider

La configurazione in cluster richiede l'impostazione del parametro wsrep_cluster_address che prende forma di URL gcomm://[IP]. Anche se e' possibile effettuare l'impostazione su file di configurazione e' piu' comodo utilizzare la linea di comando. Il primo nodo che definisce il cluster utilizzera' il comando:

Come su ogni DB MySQL il tuning dei parametri si effettua agendo sul file my.cnf. Ecco un esempio:

# /etc/my.cnf.d/server.cnf

query_cache_size=0
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
innodb_doublewrite=1
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_address=gcomm://10.0.0.20,10.0.0.30
wsrep_cluster_name='XeClu01'
wsrep_node_address='10.0.0.10'
wsrep_node_name='db01'
wsrep_sst_method=rsync
wsrep_sst_auth=root:password

Nelle versioni piu' rececenti del cluster viene utilizzato il comando gm-installer, da eseguire come utente root su un linux box senza pacchetti aggiuntivi.

Avvertenze per l'uso

L'utilizzo di Galera Cluster puo' richiedere alcune modifiche alle applicazioni che debbono soddisfare alcune regole.

• Viene replicato solo l'Engine InnoDB
• Ogni tabella deve avere una chiave primaria
• Le transazioni possono ricevere l'errore Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK) e debbono essere in grado di gestirlo (eg. risottomettendo la transazione). In alcuni casi (network partitioning) puo' essere ricevuto l'errore ERROR 1047 (08501) Unknown Command.
• Non sono supportati: LOCK/UNLOCK table; funzioni di lock (eg. GET_LOCK); transazioni XA; ...
• La dimensione massima della trasazioni e' definita dai parametri wsrep_max_ws_rows e wsrep_max_ws_size

Dal punto di vista del DBA non sono molte le differenze... ma dal punto di vista pratico si tratta di DB da gestire "con attenzione".
L'unico engine supportato e' InnoDB. Gli statement DDL vengono replicati come statement ma e' molto opportuno eseguirli sui singoli nodi "in isolamento" [NdA sono disponibili due modalita': Total Order Isolation (TOI) e Rolling Schema Upgrade (RSU)]. L'uso diretto delle tabelle del data dictionary non e' supportato: un UPDATE mysql.user SET... non viene eseguito ma viene correttamente replicato un SET PASSWORD... Non sono supportati il query logging su tabella e la query cache.
Le versioni disponibili e certificate vanno scelte con cura [NdA galera cluster NON e' disponibile per la versione 5.7 di MySQL] [NdE Galera Cluster ora e' disponibili anche per la versione 5.7 ed 8.0 di MySQL e viene distribuito con tutte le versioni di MariaDB], le configurazioni in replica asincrona non sono tutte utilizzabili.
Dal punto di vista del tuning le prestazioni di Galera sono molto influenzate dal valore dei parametri di durability: innodb_flush_log_at_trx_commit e sync_binlog. Purtroppo i valori piu' conservativi sono anche quelli che forniscono le prestazioni inferiori...

Sul sito ufficiale e' disponibile un'ampia e dettagliata documentazione sulle differenze di Galera cluster con uno Stand-Alone MySQL Server.

Amministrazione (FAQ)

La gestione di Galera Cluster richiede un impegno limitato da parte del DBA. Ma qualcosa bisogna comunque fare...
Cosa si deve controllare e come e' possibile agire quando si verificano dei problemi? In questo capitolo vengono riportate le indicazioni relative ai casi piu' comuni.

• Come si attiva il cluster?
  • Il primo nodo attiva il cluster eseguendo il comando:
    # service mysql start --wsrep-new-cluster

• Come si aggiungono nodi al cluster?
  • I nodi successivi si aggiungono al cluster con il comando:
    mysql> SET GLOBAL wsrep_cluster_address='gcomm://IP address:4567';
    Per completare l'operazione di collegamento al cluster debbono essere ribaltati i dati. Questa avviene automaticamente come SST o IST.

• Cos'e' l'SST?
  • Lo State Snapshot Transfer e' la copia completa dei dati da un nodo (donor) ad un nuovo nodo (joiner). Vi sono diversi metodi di trasferimento dei dati che possono essere logici (eg. mysqldump) o fisici (eg. rsync). Alcuni sono bloccanti per il donor (che esegue una FLUSH TABLES WITH READ LOCK), ma in ogni caso il rallentamento sul donor e' significativo.

• Cos'e' l'IST?
  • Lo Incremental state transfer (IST) e' la copia dei dati da un nodo (donor) ad un nodo (joiner) che aveva gia' fatto parte del cluster in precedenza. Si tratta di un trasferimento di dati incrementale e quindi piu' efficiente dell'SST. L'IST non e' bloccante per il donor. I write set mancanti sul joiner debbono essere ancora presenti nella donor GCache, altrimenti e' necessario utilizzare l'SST.

• Come si controlla lo stato del cluster? (versione facile)
  • Si controlla il risultato dei seguenti comandi:

    SHOW GLOBAL STATUS LIKE 'wsrep_cluster_status'; 
    Deve essere Primary
    
    SHOW GLOBAL STATUS LIKE 'wsrep_cluster_size'; 
    Deve riportare il numero totale di nodi del cluster
    
    SHOW STATUS LIKE 'wsrep_local_state_comment';  
    In una situazione normale tutti i nodi debbono restituire Synced
    Gli stati possibili sono: Initialized, Joining, Waiting on SST, Joined, Donor, Synced.
    

• Come si controlla lo stato del cluster? (TL;DR)
  • Tutte le informazioni sullo stato del cluster si ottengono con il comando:
    mysql> SHOW VARIABLES LIKE 'wsrep_%'; mysql> SHOW global status LIKE 'wsrep_%';
    Le variabili piu' interessanti per il controllo del cluster, oltre a quelle gia' riportate sopra, sono: wsrep_cluster_state_uuid wsrep_cluster_conf_id wsrep_flow_control_sent wsrep_local_recv_queue% wsrep_local_send_queue_avg wsrep_flow_control_paused wsrep_cert_deps_distance

• Come si controlla lo stato di un nodo?
  • Le variabili piu' interessanti per il controllo dei nodi sono: wsrep_ready wsrep_connected wsrep_local_state_comment

• Come si impostano controlli automatici?
  • E' possibile impostare con wsrep_notify_cmd il comando da lanciare quando avviene un cambiamento di stato nel cluster.

• In caso di crash dove si trovano le informazioni sullo stato dei nodi?
  • Nel file grastate.dat.

Per maggiori dettagli si puo' far riferimento alla documentazione ufficiale.

Manual Bootstrap

Nel caso in cui un nodo vada in down e venga riagganciato non e' necessaria alcuna operativa poiche' con Galera questo avviene automaticamente (con le impostazioni di default).

Nel caso pero' in cui venga perso il quorum e' necessario il bootstrap manuale del cluster. In questo capitolo descriviamo i passi necessari [NdA utilizzando i comandi su MariaDB che e' un fork di MySQL piu' utilizzati con Galera].
Il primo passo e' determinare il nodo piu' aggiornato:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_last_committed'"

A questo punto e' necessario effettuare lo shutdown di tutti i DB tirando giu' per ultimo quello piu' aggiornato (eg. systemctl stop mariadb).
Ora va riavviato per primo il nodo piu' aggiornato con:

galera_new_cluster

Il cluster e' ora nuovamente attivo anche se con un solo nodo. I nodi successivi si agganceranno automaticamente lanciando

systemctl start mariadb

Non dovrebbe servire mai... ma nel caso in cui non partano i DB controllare il file /var/lib/mysql/grastate.dat eventualmente impostando safe_to_bootstrap=1.

Galera vs NDB

MySQL puo' essere utilizzato in configurazione di cluster NDB con cui i dati vengono partizionati e distribuiti su piu' sistemi permettendo di disporre continuamente delle informazione anche in caso di caduta di un server.

Il cluster e' costituito da nodi che svolgono tra differenti funzioni:

• MySQL deamon: il server MySQL che eseguere i comandi SQL degli utenti e richiede i dati agli Storage Node quando viene utilizzato l'Engine NDB
• Storage Node: mantiene i dati in forma replicata sincronizzandosi con gli altri Storage Node
• Management Node: si occupa della gestione degli Storage Node, mantiene la configurazione

Gli Storage Node mantengono i dati allineati tra loro utilizzando un'ampia cache in memoria e dialogando sulla porta 1186 con il nodo di Management. I dati vengono distribuiti in sharding tra i nodi mantenendo un numero stabilito di repliche. Ogni nodo mantiene in memoria l'intero DB che gli e' stato assegnato. L'occupazione per ogni singolo nodo e' pari alla dimensione del DB per il numero di repliche (due di default) diviso il numero di storage node.

Il cluster NDB e' utilizzato con applicazioni che richiedono un'elevata affidabilita', uno SLA 7x24 ed una logica applicativa semplice (eg. applicazioni telefoniche). Puo' essere utile confrontare le caratteristiche di Galera Cluster con NDB.

Win:

• Application impact
  Sia il cluster Galera che NDB impongono verifiche/modifiche sulle applicazioni. Galera pero' utilizza InnoDB che e' l'Engine piu' diffuso mentre MySQL cluster richiede l'utilizzo dell'Engine NDB che presenta parecchie differenze e limitazioni rispetto all'InnoDB.
• Join, complex queries, ...
  NDB non e' ottimizzato per eseguire join o query complesse che possono essere notevolmente piu' lente a causa dello sharding dei dati. Galera al contrario in fase di lettura utilizza tutte le ottimizzazioni [NdE quasi tutte: non si puo' utilizzare la query cache] e funzionalita' di un normale MySQL.

• Sharding
  L'Engine NDB effettua lo sharding automatico dei dati tra i nodi configurati. Con Galera ogni nodo mantiene una copia di tutti i dati.
• Supporto
  L'Engine NDB e' nato come soluzione esterna a MySQL ma da molto tempo e' supportato, mantenuto ed utilizzato in installazioni molto significative mentre Galera Cluster e' molto piu' recente e supportato ufficialmente solo dai fork MySQL (MariaDB e Percona Server).

• HA
  Entrambe le soluzioni garantiscono un'elevata affidabilita'.

Galera vs Replication

La replicazione standard di MySQL e' asincrona e, generalmente, statement based.

Nella replicazione MySQL il Master registra su file (bin-log) tutti gli statement che vengono eseguiti sulla base dati e che operano una qualche modifica ai dati (DML e DDL).
Lo Slave si collega con un thread al Master, raccoglie il contenuto dei bin-log, lo trasferisce in locale e quindi si occupa di applicarlo alla base dati.

La replicazione di MySQL e' molto diffusa perche' efficiente e semplice da configurare e mantenere. Puo' essere utile confrontare le caratteristiche di Galera Cluster con la Replication MySQL.

Win:

• HA
  Galera mantiene i nodi disponibili in lettura e scrittura a tutti gli accessi e risolve automaticamente i casi di uscita e di rientro nel cluster. Con la replica le operazioni di failover sono piu' complesse e, sopratutto, richiedono un intervento manuale.
• No Delay
  La replicazione MySQL e' asincrona ed e' quindi presente un ritardo tra il master ed i nodi slave.
• Multi-master
  La replicazione MySQL non supporta, in modo affidabile e gestibile, la modalita' multi-master.

• Conflitti
  La replication non presenta mai conflitti poiche' le modifiche vengono eseguite su un solo Master. Con Galera sono pero' possibili conflitti e le applicazioni vanno scritte o utilizzate in modo che non si verifichino.
• Impatto applicativo
  Vi sono diverse limitazioni alle applicazioni che utilizzano Galera. Anche la replication ha alcune limitazioni sugli statement/funzioni SQL da utilizzare ma sono meno che con Galera.
• Supporto
  La replicazione MySQL e' disponibile da sempre, ben supportata e mantenuta da MySQL e da tutti i fork mentre Galera Cluster e' molto piu' recente supportata solo da alcuni fork MySQL (MariaDB e Percona Server)
• DDL
  Galera ha difficolta' maggiori nel gestire le DDL. Sarebbero semplicemente da evitare! E' quindi maggiormente adatto ad applicazioni/ambienti stabili che non richiedono modifiche nella struttura della base dati.
• Latenza
  La replicazione MySQL ben sopporta connessioni con un'alta latenza. La replicazione sincrona di Galera viene invece rallentata.

• Cloud
  Anche se con modalita' differenti entrambe le architetture supportano bene e vengono spesso usate in configurazioni in Cloud.
• Scalabilita' in lettura
  Entrambe le tecnologie sono notevolmente scalabili in lettura.
• Performance
  Le performance di entrambe le tecnologie sono molto elevate e vicine a quelle di un server standalone.

Nel valutare i punti riportati sopra e' opportuno ricordare che Galera usa la replication e che sono possibili configurazione miste (eg. un cluster galera in LAN replicato in WAN su un sito di DR).

Galera vs Group Replication

La Group Replication e' stata introdotta di recente come Plugin nell'ultima versione di MySQL [NdE 5.7.17]. L'architettura di Galera Cluster e della Group Replication e' analoga e la tecnologia utilizzata e' simile.

Win:

• Proven
  Galera e' disponibile da piu' tempo in GA ed e' gia' utilizzata in parecchi ambienti di produzione.
• Features
  Galera offre alcune funzionalita' aggiuntive (eg. arbitrator, node weight, sync wait, notify command, ...)

• Supporto
  La Group Replication e' mantenuta da MySQL/Oracle che ha una base di installato molto forte. Il supporto di Galera e' garantito anche da Percona e da MariaDB che tecnicamente sono ineccepibili ma hanno minore diffusione.

• Performance
  Anche se e' stato pubblicato di recente un interessante benchmark le due tecnologie sono simili e le prestazioni dovrebbero convergere nei casi reali.

Nel valutare i punti riportati sopra e' opportuno ricordare che la Group Replication e' stata appena introdotta come versione di produzione e quindi le valutazioni riportate sono provvisorie.

Ancora piu' recente [NdE 12 Aprile 2017] e' l'introduzione di InnoDB Cluster che completa l'architettura della Group Replication utilizzando il proxy MySQL-Router e il tool MySQL-Shell... quindi i confronto e' appena iniziato.

Varie ed eventuali

Galera Cluster for MySQL e' disponibile per Oracle MySQL Community, MariaDB, and Percona.

Un'indicazione sommaria delle release di Galera e' riportata nello schema seguente [NdE la versione aggiornata e' mantenuta in You Server Stinks per MySQL e Galera]:

(Sources: Galera Cluster, Git Hub Launchpad (old) MariaDB )

Titolo: MySQL Galera Cluster
Livello: Avanzato (3/5)
Data: 14 Febbraio 2015 ❤️
Versione: 1.0.6 - 31 Ottobre 2020 🎃
Autore: mail [AT] meo.bogliolo.name