MariaDB Galera Cluster : multi-master synchrone

MariaDB Galera Cluster : multi-master synchrone

Construisez un cluster MariaDB multi-master 3 nodes avec Galera : replication synchrone, ecriture sur n'importe quel node, failover automatique. La solution standard pour la HA MariaDB / MySQL.

Introduction

Galera Cluster est une extension MariaDB/MySQL pour la replication synchrone multi-master :

  • Toutes les ecritures sont propagees synchroniquement aux autres nodes
  • Vous pouvez ecrire sur n'importe quel node
  • Le failover est automatique (chaque node est "primary")
  • Strong consistency (pas de lecture eventuelle)
  • Minimum 3 nodes recommande (pour eviter le split-brain)

Limites :

  • Toutes les tables doivent etre InnoDB (pas de MyISAM, pas de TokuDB)
  • Les transactions LARGE peuvent etre rejetees (taille / lock contention)
  • Latence d'ecriture = latence reseau entre les nodes

Cas d'usage : applications LAMP a forte ecriture (WordPress avec gros traffic, e-commerce, SaaS).

Prerequis

  • 3 VPS Linux Debian / Ubuntu
  • Reseau prive entre les VPS (LAN ou VPN)
  • IPs : 10.0.0.1, 10.0.0.2, 10.0.0.3
  • Acces root sur chaque

Etape 1 : Installation MariaDB sur les 3 nodes

sudo apt update
sudo apt install -y mariadb-server mariadb-client galera-4

Verifiez :

mariadb --version

Etape 2 : Configurer firewall

Galera utilise plusieurs ports :

  • 3306 : MariaDB SQL
  • 4567 : replication Galera (TCP + UDP)
  • 4568 : Incremental State Transfer (IST)
  • 4444 : State Snapshot Transfer (SST)

Sur chaque node :

sudo ufw allow from 10.0.0.0/24 to any port 3306
sudo ufw allow from 10.0.0.0/24 to any port 4567 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 4567 proto udp
sudo ufw allow from 10.0.0.0/24 to any port 4568
sudo ufw allow from 10.0.0.0/24 to any port 4444

Etape 3 : Stopper MariaDB partout

sudo systemctl stop mariadb

Etape 4 : Configurer Galera

Sur chaque node, creez /etc/mysql/mariadb.conf.d/60-galera.cnf :

[mysqld]
binlog_format=ROW
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=2
innodb_buffer_pool_size=2G

bind-address=0.0.0.0

wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="my_cluster"
wsrep_cluster_address="gcomm://10.0.0.1,10.0.0.2,10.0.0.3"
wsrep_sst_method=mariabackup
wsrep_sst_auth=sstuser:sst-pass-fort

# Specifique a chaque node : remplacez par l'IP du node
wsrep_node_address="10.0.0.1"
wsrep_node_name="node1"

⚠️ Sur node2 : wsrep_node_address="10.0.0.2" et wsrep_node_name="node2". Idem pour node3.

Etape 5 : Creer l'utilisateur SST

Sur node1 uniquement, demarrez d'abord en mode classique :

sudo systemctl start mariadb
sudo mariadb
CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'sst-pass-fort';
GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';
FLUSH PRIVILEGES;

Stoppez :

sudo systemctl stop mariadb

Etape 6 : Bootstrapper le cluster

Sur node1 :

sudo galera_new_cluster

Cette commande demarre MariaDB et initialise le cluster (le premier node n'a personne avec qui synchroniser, il faut donc un bootstrap).

Verifiez :

sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Devrait afficher wsrep_cluster_size = 1.

Etape 7 : Demarrer node2 et node3

Sur node2 :

sudo systemctl start mariadb

Patientez. Le node copie la base depuis node1 (via SST mariabackup).

sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Devrait afficher 2 une fois le sync termine.

Pareil sur node3 :

sudo systemctl start mariadb
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"

Devrait afficher 3.

Etape 8 : Verifier la replication

Sur node1 :

CREATE DATABASE test;
USE test;
CREATE TABLE foo (id INT AUTO_INCREMENT PRIMARY KEY, msg VARCHAR(100));
INSERT INTO foo (msg) VALUES ('Hello from node1');

Sur node2 et node3 :

USE test;
SELECT * FROM foo;

La donnee est presente partout, en temps reel.

Maintenant ecrivez sur node2 :

INSERT INTO foo (msg) VALUES ('Hello from node2');
SELECT * FROM foo;

Toutes les ecritures sont visibles sur les 3 nodes.

Etape 9 : Status detaille

SHOW STATUS LIKE 'wsrep_%';

Variables importantes :

  • wsrep_cluster_size : nombre de nodes UP
  • wsrep_cluster_status : Primary (OK) / non-Primary (split-brain)
  • wsrep_connected : ON
  • wsrep_ready : ON
  • wsrep_local_state_comment : Synced (OK)

Etape 10 : Failover

Stoppez un node :

sudo systemctl stop mariadb

Sur les autres :

SHOW STATUS LIKE 'wsrep_cluster_size';   -- 2

Le cluster fonctionne toujours. Les ecritures continuent. Au redemarrage du node tombe, il rattrape automatiquement (IST si peu de changes, SST sinon).

⚠️ Si vous perdez 2 nodes sur 3, le dernier passe en non-Primary (refus d'ecriture) pour eviter le split-brain. Il faut alors le forcer en bootstrap manuel :

sudo mariadb -e "SET GLOBAL wsrep_provider_options='pc.bootstrap=YES';"

Etape 11 : Load balancer devant

Pour avoir un seul endpoint pour vos apps, placez HAProxy ou ProxySQL devant :

/etc/haproxy/haproxy.cfg (HAProxy) :

frontend galera_front
    bind *:3306
    mode tcp
    default_backend galera_back

backend galera_back
    mode tcp
    balance leastconn
    option httpchk
    server node1 10.0.0.1:3306 check port 9200 inter 2s
    server node2 10.0.0.2:3306 check port 9200 inter 2s
    server node3 10.0.0.3:3306 check port 9200 inter 2s

Pour le healthcheck HTTP, installez xinetd + clustercheck sur chaque node.

Etape 12 : Backups

Vos backups MariaDB classiques fonctionnent sur Galera. Recommandation : faites le backup depuis un node specifique (par exemple node3) pour ne pas charger les nodes en ecriture.

sudo mariadb-backup --backup --target-dir=/var/backups/mariadb-$(date +%F) --user=root

Ou avec mysqldump :

sudo mysqldump --all-databases --single-transaction | gzip > /var/backups/all-$(date +%F).sql.gz

Depannage

"WSREP: Failed to open channel"

Reseau bloque. Verifiez :

nc -zv 10.0.0.2 4567
nc -zv 10.0.0.2 4444

SST echoue

Verifiez les credentials sstuser et que mariabackup est installe partout :

sudo apt install -y mariadb-backup

Split-brain (non-Primary)

Le cluster a perdu le quorum. Si la majorite est down, restaurez les nodes ou forcez le bootstrap sur celui qui a les donnees les plus a jour :

SHOW STATUS LIKE 'wsrep_last_committed';

Le node avec la plus grande valeur est le plus a jour. Bootstrap dessus.

Performance dégradée

Galera ajoute de la latence (synchrone). Si vos apps font beaucoup de petites transactions, regroupez-les. Activez aussi innodb_flush_log_at_trx_commit=2 (moins safe mais plus rapide).

Commandes utiles

# Status cluster
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_cluster_size';"
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_local_state_comment';"
sudo mariadb -e "SHOW STATUS LIKE 'wsrep_%';"

# Bootstrap node1
sudo galera_new_cluster

# Start node normal
sudo systemctl start mariadb

# Logs
sudo tail -f /var/log/mysql/error.log

# Forcer un node a sortir du cluster
sudo systemctl stop mariadb

# Verifier les ports Galera
sudo ss -tunlp | grep -E '3306|4444|4567|4568'

Conclusion

Galera Cluster vous offre :

  • Multi-master synchronous
  • Failover automatique
  • Lectures et ecritures distribuees

Limites :

  • Latence d'ecriture = reseau entre nodes
  • Tables InnoDB only
  • 3 nodes minimum pour eviter split-brain

Pour aller plus loin :

  • Utilisez HAProxy ou ProxySQL devant pour un endpoint unique
  • Combinez avec MaxScale pour du routing intelligent
  • Pour du multi-DC, regardez la documentation Galera segments

Ressources

Join our Discord community server

For any questions, suggestions, or just to chat with the community, join us on Discord!

900+Members