A differenza del server MySQL standard e del cluster MySQL, il modo per avviare un cluster MySQL/MariaDB Galera è leggermente diverso. Galera richiede di avviare un nodo in un cluster come punto di riferimento, prima che i nodi rimanenti possano unirsi e formare il cluster. Questo processo è noto come bootstrap del cluster. Il bootstrapping è un passaggio iniziale per introdurre un nodo di database come componente principale, prima che altri lo vedano come punto di riferimento per sincronizzare i dati.
Come funziona?
Quando Galera inizia con il comando bootstrap su un nodo, quel particolare nodo raggiungerà lo stato primario (controlla il valore di wsrep_cluster_status). I nodi rimanenti richiederanno solo un normale comando di avvio e cercheranno automaticamente il componente primario (PC) esistente nel cluster e si uniranno per formare un cluster. La sincronizzazione dei dati avviene quindi tramite il trasferimento di stato incrementale (IST) o il trasferimento di stato snapshot (SST) tra il partecipante e il donatore.
Quindi, in pratica, dovresti eseguire il bootstrap del cluster solo se desideri avviare un nuovo cluster o quando nessun altro nodo nel cluster è nello stato PRIMARY. È necessario prestare attenzione quando si sceglie l'azione da intraprendere, altrimenti potresti ritrovarti con cluster divisi o perdita di dati.
I seguenti scenari di esempio illustrano quando eseguire il bootstrap di un cluster a tre nodi in base allo stato del nodo (wsrep_local_state_comment) e allo stato del cluster (wsrep_cluster_status):
| Stato di Galera | Flusso del cinturino |
|---|---|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
Come avviare Galera Cluster?
I 3 fornitori di Galera utilizzano diversi comandi di bootstrap (basati sull'ultima versione del software). Sul primo nodo, esegui:
-
Cluster MySQL Galera (codership):
$ service mysql bootstrap # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line -
Cluster Percona XtraDB (Percona):
$ service mysql bootstrap-pxc # sysvinit $ systemctl start [email protected] # systemd -
Cluster MariaDB Galera (MariaDB):
$ service mysql bootstrap # sysvinit $ service mysql start --wsrep-new-cluster # sysvinit $ galera_new_cluster # systemd $ mysqld_safe --wsrep-new-cluster # command line
Il comando sopra è solo un wrapper e quello che fa effettivamente è avviare l'istanza MySQL su quel nodo con gcomm:// come variabile wsrep_cluster_address. Puoi anche definire manualmente le variabili all'interno di my.cnf ed eseguire il comando standard di avvio/riavvio. Tuttavia, non dimenticare di modificare nuovamente wsrep_cluster_address per contenere gli indirizzi di tutti i nodi dopo l'inizio.
Quando il primo nodo è attivo, esegui il seguente comando sui nodi successivi:
$ service mysql start
$ systemctl start mysqlIl nuovo nodo si connette ai membri del cluster come definito dal parametro wsrep_cluster_address. Ora recupererà automaticamente la mappa del cluster e si connetterà al resto dei nodi e formerà un cluster.
Avviso:non eseguire mai il bootstrap quando desideri ricollegare un nodo a un cluster esistente e NON eseguire MAI il bootstrap su più di un nodo.
Bandiera Safe-to-Bootstrap
Galera a partire dalla versione 3.19 viene fornito con un nuovo flag chiamato "safe_to_bootstrap" all'interno di grastate.dat. Questo flag facilita la decisione e previene scelte non sicure tenendo traccia dell'ordine in cui i nodi vengono chiusi. L'ultimo nodo che è stato spento verrà contrassegnato come "Safe-to-Bootstrap". Tutti gli altri nodi verranno contrassegnati come non sicuri da cui eseguire il bootstrap.
Osservando il contenuto di grastate.dat (l'impostazione predefinita è sotto MySQL datadir) dovresti notare il flag nell'ultima riga:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: 2575
safe_to_bootstrap: 0Durante il bootstrap del nuovo cluster, Galera rifiuterà di avviare il primo nodo contrassegnato come non sicuro da cui eseguire il bootstrap. Vedrai il seguente messaggio nei log:
"Potrebbe non essere sicuro eseguire il bootstrap del cluster da questo nodo. Non è stato l'ultimo a lasciare il cluster e potrebbe non contenere tutti gli aggiornamenti.
Per forzare il bootstrap del cluster con questo nodo, modifica manualmente il file grastate.dat e imposta safe_to_bootstrap su 1 ."
In caso di arresto non pulito o arresto anomalo, tutti i nodi avranno "safe_to_bootstrap:0", quindi dobbiamo consultare il motore di archiviazione InnoDB per determinare quale nodo ha commesso l'ultima transazione nel cluster. Questo può essere ottenuto avviando mysqld con la variabile "--wsrep-recover" su ciascuno dei nodi, che produce un output come questo:
$ mysqld --wsrep-recover
...
2016-11-18 01:42:15 36311 [Note] InnoDB: Database was not shutdown normally!
2016-11-18 01:42:15 36311 [Note] InnoDB: Starting crash recovery.
...
2016-11-18 01:42:16 36311 [Note] WSREP: Recovered position: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f:114428
...Il numero dopo la stringa UUID nella riga "Posizione recuperata" è quello da cercare. Scegli il nodo con il numero più alto e modifica il suo grastate.dat per impostare "safe_to_bootstrap:1", come mostrato nell'esempio seguente:
# GALERA saved state
version: 2.1
uuid: 8bcf4a34-aedb-14e5-bcc3-d3e36277729f
seqno: -1
safe_to_bootstrap: 1È quindi possibile eseguire il comando bootstrap standard sul nodo scelto.
E se i nodi si sono discostati?
In determinate circostanze, i nodi possono essersi discostati l'uno dall'altro. Lo stato di tutti i nodi potrebbe diventare non primario a causa della divisione della rete tra nodi, dell'arresto anomalo del cluster o se Galera ha riscontrato un'eccezione durante la determinazione del componente primario. Dovrai quindi selezionare un nodo e promuoverlo come componente principale.
Per determinare quale nodo deve essere avviato, confronta il valore wsrep_last_committed su tutti i nodi DB:
node1> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10032 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+node2> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 10348 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+node3> SHOW STATUS LIKE 'wsrep_%';
+----------------------+-------------+
| Variable_name | Value |
+----------------------+-------------+
| wsrep_last_committed | 997 |
...
| wsrep_cluster_status | non-Primary |
+----------------------+-------------+Dagli output precedenti, node2 ha i dati più aggiornati. In questo caso, tutti i nodi Galera sono già avviati, quindi non è necessario riavviare nuovamente il cluster. Abbiamo solo bisogno di promuovere node2 per essere un componente primario:
node2> SET GLOBAL wsrep_provider_options="pc.bootstrap=1";I nodi rimanenti si ricollegheranno quindi al componente principale (nodo2) e risincroceranno i propri dati in base a questo nodo.
Se stai usando ClusterControl (provalo gratuitamente), puoi determinare wsrep_last_committed e wsrep_cluster_status direttamente da ClusterControl> Panoramica pagina:
Oppure da ClusterControl> Performance> Stato DB pagina:
