MariaDB offre due diverse soluzioni ad alta disponibilità (HA) e clustering. Il primo è la replica master/slave MariaDB standard che può essere configurata in diverse topologie principalmente per il bilanciamento del carico, HA e scopi di backup. Il secondo è MariaDB Galera, una soluzione di clustering sincrono multi-master. Le sue caratteristiche principali sono le seguenti:
- Multi-master:tutti i nodi in un cluster Galera possono eseguire operazioni di lettura e scrittura, offrendo una migliore scalabilità.
- I nodi possono unirsi a un cluster automaticamente e vengono rimossi in caso di errore.
- La replica di Galera è sincrona, il che significa che le modifiche su un nodo sono garantite per essere applicate agli altri nodi. In teoria, questo garantisce che nessun dato venga perso quando un nodo si guasta.
Questa guida ti guiderà attraverso l'installazione di MariaDB e la sua configurazione in un cluster Galera. Useremo tre nodi Debian 10 per la dimostrazione, sebbene sia possibile utilizzare qualsiasi numero (≥3) di nodi. La configurazione di due nodi in un cluster Galera è tecnicamente possibile ma non fornisce la tolleranza agli errori poiché un nodo guasto causerà l'arresto dell'altro nodo.
Requisiti
- Tre o più istanze Debian 10.
- Accesso all'utente root oa qualsiasi utente con privilegi sudo.
- Il $EDITOR è necessario impostare la variabile di ambiente.
NOTA: I cluster Galera possono funzionare su WAN o LAN. Se i tuoi nodi condividono una rete privata, usa indirizzi IP privati ove applicabile. In caso contrario, è necessario utilizzare gli indirizzi WAN.
Se si utilizza un utente sudo, aprire e utilizzare una shell di root per la durata di questa configurazione utilizzando:
sudo -s
Passaggio 1:installazione di MariaDB
Questo passaggio dovrebbe essere eseguito su tutti i nodi.
Utilizzare i seguenti comandi per installare MariaDB, la libreria Galera e Rsync. Quest'ultimo è usato da Galera.
apt update apt install -y mariadb-server mariadb-client galera-3 rsync
Assicurati che il servizio MariaDB sia abilitato:
systemctl enable mariadb.service
Proteggi le tue istanze MariaDB utilizzando lo script mysql_secure_installation:
mysql_secure_installation
Rispondi alle domande come mostrato di seguito e assicurati di scegliere una password complessa per l'utente root di MySQL.
Enter current password for root (enter for none): Press <Enter> Set root password? [Y/n] y New password: your_password Re-enter new password: your_password Remove anonymous users? [Y/n] y Disallow root login remotely? [Y/n] y Remove test database and access to it? [Y/n] y Reload privilege tables now? [Y/n] y All done! If you've completed all of the above steps, your MariaDB installation should now be secure.
Fase 2:configurazione di MariaDB
Questo passaggio dovrebbe essere eseguito su tutti i nodi.
Arresta il servizio MariaDB su tutti i nodi:
systemctl stop mariadb.service
Per impostazione predefinita, il demone MariaDB ascolta solo le connessioni su localhost. Affinché il cluster funzioni, è necessario modificarlo in un indirizzo accessibile dall'esterno. Per farlo, modifica il file delle opzioni /etc/mysql/mariadb.conf.d/50-server.cnf:
$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf
Trova la riga seguente:
bind-address = 127.0.0.1
Se stai utilizzando una rete privata per il cluster e non vuoi esporre MariaDB ad altre reti (es. WAN), specifica l'indirizzo IPv4 locale per ogni nodo. Altrimenti, usa 0.0.0.0 che indica a MariaDB di ascoltare su tutte le interfacce. Ad esempio:
bind-address = 0.0.0.0
Salva la modifica ed esci dall'editor di testo.
Ora configureremo le opzioni relative al cluster. Crea un nuovo file di opzioni:
$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf
Immettere la seguente configurazione ragionevole nel file, sostituendo gli indirizzi IP. Dovrebbe essere identico su tutti i nodi.
[galera]
wsrep_on = on wsrep_provider = /lib/galera/libgalera_smm.so wsrep_cluster_address = gcomm://192.0.2.1,192.0.2.2,192.0.2.3 wsrep_cluster_name = galera_cluster_0 default_storage_engine = InnoDB innodb_autoinc_lock_mode = 2 innodb_doublewrite = 1 binlog_format = ROW
- wsrep_on =on abilita la replica dei set di scrittura, la funzionalità sottostante utilizzata da Galera.
- wsrep_provider specifica il percorso della libreria galera. È fornito dal pacchetto galera-3 in /lib/galera/libgalera_smm.so su Debian 10.
- wsrep_cluster_address deve contenere almeno un indirizzo di un altro membro del cluster. Si consiglia di elencare tutti i membri del cluster. Non è necessario un ordine particolare.
- wsrep_cluster_name dovrebbe essere univoco per il cluster e dovrebbe essere identico su tutti i nodi dello stesso cluster galera.
- Le restanti opzioni sono necessarie per il corretto funzionamento di Galera e non devono essere modificate.
Fase 3:bootstrap del cluster
Assicurati che MariaDB sia fermo/inattivo su tutti i nodi prima di procedere:
systemctl status mariadb.service
Per avviare il cluster, un nodo deve prima crearlo. Su Debian 10, questo può essere fatto con lo script galera_new_cluster. Lo script deve essere eseguito solo su un nodo e solo una volta per inizializzare il cluster.
galera_new_cluster
Questo avvierà MariaDB sul nodo corrente. Assicurati che sia in esecuzione con:
systemctl status mariadb.service
Quindi avvia MariaDB sugli altri nodi con:
systemctl start mariadb.service
Il cluster dovrebbe ora essere operativo.
Fase 4:test
Per assicurarti che il cluster funzioni come previsto, seleziona un nodo qualsiasi e accedi a MariaDB:
mysql -u root -p
Emetti la seguente dichiarazione per creare un database:
> CREATE DATABASE test0; > \q
Quindi controlla questo nuovo database su tutti gli altri nodi:
mysql -u root -p -e "SHOW DATABASES;"
Il comando precedente dovrebbe restituire un elenco contenente test0:
+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | test0 | +--------------------+
Potresti voler eseguire un test più approfondito scrivendo nel cluster da ogni nodo. Una volta che sei soddisfatto del test, ripulisci tutti i database non necessari dal cluster. Qualsiasi nodo può essere utilizzato.
mysql -u root -p -e "DROP DATABASE test0;"
Passaggio 5:suggerimenti per la risoluzione dei problemi
Utilizzare la query seguente per visualizzare informazioni sullo stato corrente del nodo/cluster:
mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_REPL_LATENCY','WSREP_EVS_DELAYED','WSREP_READY');"
Un cluster a 3 nodi integro dovrebbe restituire quanto segue:
+---------------------------+----------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------------+----------------+ | WSREP_CLUSTER_SIZE | 3 | | WSREP_CLUSTER_STATUS | Primary | | WSREP_EVS_DELAYED | | | WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 | | WSREP_LOCAL_STATE_COMMENT | Synced | | WSREP_READY | ON | +---------------------------+----------------+
- WSREP_CLUSTER_SIZE rappresenta il numero corrente di nodi nel componente del cluster.
- WSREP_CLUSTER_STATUS rappresenta lo stato del componente del cluster e non del cluster nel suo insieme.
- WSREP_EVS_DELAYED mostra un elenco di nodi ritardati. È previsto un valore vuoto da cluster integri.
- WSREP_EVS_REPL_LATENCY mostra la latenza di replica nel formato min/avg/max/stddev/samplesize. I valori vengono visualizzati in secondi. Latenze molto elevate possono portare a prestazioni ridotte.
- WSREP_LOCAL_STATE_COMMENT mostra lo stato corrente del nodo.
- WSREP_READY indica se il nodo può accettare query.
Quando un nodo in un cluster a 3 nodi perde la connettività, il cluster viene partizionato in un componente primario costituito da 2 nodi e un componente non primario. Il componente principale non è interessato dall'interruzione e continua il normale funzionamento. Dal punto di vista del componente non primario, la query mostrata sopra restituirebbe quanto segue:
+---------------------------+--------------------------------------------------------------------------------------------------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------------+--------------------------------------------------------------------------------------------------------------------------------+ | WSREP_CLUSTER_SIZE | 1 | | WSREP_CLUSTER_STATUS | non-Primary | | WSREP_EVS_DELAYED | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907:tcp://192.0.2.1:4567:3,a421be89-fe7d-11e9-a91e-7e62f7562e58:tcp://192.0.2.3:4567:2 | | WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 | | WSREP_LOCAL_STATE_COMMENT | Initialized | | WSREP_READY | OFF | +---------------------------+--------------------------------------------------------------------------------------------------------------------------------+
Notare il valore WSREP_EVS_DELAYED, che indica problemi di connettività agli altri nodi.
Sui nodi del componente primario, la stessa query restituisce:
+---------------------------+----------------------------------------------------------------+ | VARIABLE_NAME | VARIABLE_VALUE | +---------------------------+----------------------------------------------------------------+ | WSREP_CLUSTER_SIZE | 2 | | WSREP_CLUSTER_STATUS | Primary | | WSREP_EVS_DELAYED | a2217526-fe7d-11e9-8692-1f2f0cdb403d:tcp://192.0.2.2:4567:2 | | WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 | | WSREP_LOCAL_STATE_COMMENT | Synced | | WSREP_READY | ON | +---------------------------+----------------------------------------------------------------+
Per eseguire il ripristino da guasti di un singolo nodo, non è necessario alcun intervento manuale. Quando il nodo in errore si riconnette al cluster, si sincronizza automaticamente con il cluster.
Ulteriori informazioni
Per le opzioni di configurazione avanzate, fare riferimento a Variabili di sistema di Galera Cluster.