FR Mariadb galera - titandc/titan-sc-documentation GitHub Wiki

Introduction

MariaDB Galera est une solution de clustering multi-maître permettant ainsi d'écrire sur n'importe quel noeud composant le cluster.

MariaDB Galera étant basé sur le protocole RAFT pour la prise de décision en interne dans le cluster, il est recommandé de disposer d’un nombre de noeuds impair.

Cette documentation a été testée sur :

  • Debian 11 (bullseye)
  • MariaDB 10.6

Architecture

L'architecture proposée est la suivante :

Un cluster MariaDB Galera est formé sur des serveurs de backend. Chaque machine hébergeant des sites web sera capable d'aller chercher/lire de la donnée sur un des trois serveurs de base de données. Un service haproxy est installé sur chaque machine front. Ainsi, si l'un des membres du cluster MariaDB Galera devient indisponible, le service haproxy le détectera et n'utilisera plus le membre en question pour lire/écrire de la donnée.

Pour interconnecter l'ensemble des serveurs, le réseau 192.168.0.0/24 sera utilisé avec la configuration suivante :

Serveur MariaDB Galera (backend) :

  • Nom d'hôte galera-1 : 192.168.0.253/24
  • Nom d'hôte galera-2 : 192.168.0.252/24
  • Nom d'hôte galera-3 : 192.168.0.251/24

Serveur web (frontend) :

  • Nom d'hôte web-1 : 192.168.0.2/24

Configuration du réseau

L'ensemble des machines frontend et backend doivent être mesure de se parler autrement que par leurs adresses IP publique.

Sur l'interface SmallCloud, dans la partie "Réseaux", il faut raccorder tous les serveurs web (frontend) utilisant le cluster MariaDB Galera ainsi que les serveurs de base de données sur le même switch.

Une fois raccordé, l'interface enp9s0 sera alors créée sur les machines. La prochaine étape est la configuration de cette interface. Sur chaque machine, configurez l'interface avec la bonne adresse IP :

ip addr add <IP>/<NETMASK> dev enp9s0
ip link set enp9s0 up

Vérifiez que les machines se ping entre elles.

Configuration du cluster MariaDB Galera

L’ensemble des membres du cluster MariaDB Galera devra disposer de la même version du paquet mariadb-server.

La suite des actions de ce chapitre est à faire sur les serveurs de base de données.

Installation

La dernière version de MariaDB à date d'écriture de cette documentation est la version 10.6.

Les commandes suivantes proviennent de la page de téléchargement de MariaDB.

apt-get install software-properties-common dirmngr apt-transport-https
apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc'
add-apt-repository 'deb [arch=amd64,i386,arm64,ppc64el] https://ftp.igh.cnrs.fr/pub/mariadb/repo/10.6/debian bullseye main'

Une fois la clé et le dépôt installé, il est possible d'installer MariaDB server :

apt-get update
apt-get install mariadb-server

Ces commandes sont à faire sur l'ensemble des serveurs de base de données.

Configuration

L’initialisation du cluster se fera sur un seul noeud uniquement. Les autres noeuds du cluster le rejoindront au fur et à mesure.

Cependant, la configuration reste la même sur l’ensemble des noeuds qui composeront le cluster. La configuration suivante est donc à appliquer sur tous les noeuds.

Dans un premier temps, il est nécessaire d’arrêter le serveur MariaDB :

systemctl stop mariadb

Ouvrir le fichier /etc/mysql/mariadb.conf.d/60-galera.cnf pour y ajouter ceci (exemple avec le serveur galera-1, il faut l'adapter pour chaque serveur de base de données) :

binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address="192.168.0.253" # --- A changer

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="cluster_galera"
wsrep_cluster_address="gcomm://192.168.0.253,192.168.0.252,192.168.0.251" # --- A changer

# Galera Node Configuration
wsrep_node_address="192.168.0.253" # --- A changer
wsrep_node_name="galera-1" # --- A changer

Dans le champ bind-address, il est fortement recommendé de ne pas utiliser l'adresse IP publique du serveur ! Sinon, le serveur mariadb sera exposé sur internet. Ce qui est fortement déconseillé !

Note: Il est possible d’avoir un peu plus de logs que ce que fournit la commande journalctl -fu mariadb en décommentant/modifiant la ligne suivante dans le fichier /etc/mysql/mariadb.conf.d/50-server.cnf :

log_error=/var/log/mysql/error.log

Attention à la volumétrie que cela peut représenter.

Initialisation du cluster

Sur un des noeuds du cluster (un seul uniquement), il faut initialiser le cluster MariaDB Galera en utilisant la commande suivante, par exemple le serveur galera-1 :

galera_new_cluster

L’utilisation de cette commande (qui est un simple script bash) permettra de passer l’option --wsrep-new-cluster lors du démarrage de MariaDB, ce qui aura pour effet d'initialiser le cluster.

Concernant les deux autres membres du cluster, ils doivent juste rejoindre le cluster.

Rejoindre un cluster

Ce chapitre est valable à partir du moment où un noeud a déjà initialisé le cluster en utilisant la commande galera_new_cluster. Dans le cas de la création du cluster, la commande suivante est à exécuter sur les autres membres du cluster : galera-2 et galera-3. Elle peut être utilisé pour ajouter de nouveaux membres au cluster :

systemctl start mariadb

MariaDB essaiera de se connecter à l’un des serveurs se trouvant dans sa configuration wsrep_cluster_address=. Si au moins un des serveurs est joignable, il sera alors en mesure de s’y connecter et récupèrera la liste de l’ensemble des noeuds du cluster à partir de celui-ci et rejoindra le cluster (s’il est accepté par ses pairs). Si aucun noeud n’est disponible, se référer au chapitre qui parle de la perte du cluster complet ou de l’initialisation du cluster.

Il est possible de voir à partir de n’importe quel noeud du cluster, son état avec la commande suivante (à adapter au besoin) :

mysql -u root -p -e "show status like 'wsrep_cluster%';"

D’après la documentation, MariaDB Galera utilise 4 ports :

  • 3306
  • 4567: Port de réplication de Galera. Utilise le TCP et UDP
  • 4568: Incremental State Transfer List
  • 4444: State Snapshot Transfer (SST)

Perte d’un noeud

La perte d’un noeud n’est pas grave à proprement parler mais il est préférable de ne pas laisser trop longtemps le cluster dans cet état car la prise de décision peut s’en retrouver affectée car le quorum n’est plus atteint.

Pour vérifier qu’un noeud a disparu du cluster, la commande suivante permet de visualiser le nombre de noeud présent dans le cluster à partir d’un noeud sain :

mysql -u root -e "show status like 'wsrep_cluster%';"

Pour connaître le nom du/des noeud(s) restant(s) ou absent(s), il faut aller lire le fichier de log /var/log/mysql/error.log (si activé). Ce type de lignes sera présent et indiquera les noeuds restants :

2021-10-28 16:13:32 0 [Note] WSREP: Deferred close timer started for socket with remote endpoint: tcp://192.168.0.252:40522
2021-10-28 16:13:32 0 [Note] WSREP: forgetting 32dae230-94a6 (tcp://192.168.0.252:4567)
2021-10-28 16:13:32 0 [Note] WSREP: Deferred close timer handle_wait Operation aborted. for 0x562f393f5840
2021-10-28 16:13:32 0 [Note] WSREP: Deferred close timer destruct

[...]

2021-10-28 16:13:32 2 [Note] WSREP: ================================================
View:
  id: 42d895db-37c3-11ec-bf4d-3e726e21fed5:44
  status: primary
  protocol_version: 4
  capabilities: MULTI-MASTER, CERTIFICATION, PARALLEL_APPLYING, REPLAY, ISOLATION, PAUSE, CAUSAL_READ, INCREMENTAL_WS, UNORDERED, PREORDERED, STREAMING, NBO
  final: no
  own_index: 0
  members(2):
        0: 0a07c4c2-37f3-11ec-bf5c-af4c93cfb413, galera-1
        1: 346df9ad-37f9-11ec-bd58-5a6cfee821df, galera-3
=================================================

On voit ici qu’il manque le serveur galera-2.

Dans tous les cas, le (re-)démarrage du service sera nécessaire (sur le serveur étant porté disparu). Une resynchronisation sera faite auprès de ses pairs lorsque le noeud tombé aura rejoint le cluster.

systemctl restart mariadb.service

Perte complet du cluster

Lorsque tous les noeuds du cluster sont tombés, il faut trouver le noeud étant tombé en dernier pour le relancer en premier. C’est potentiellement celui-ci qui aura les données les plus à jour.

De la même manière que lors du premier lancement du cluster, il faut utiliser la commande suivante sur le noeud qui est tombé en dernier :

galera_new_cluster

Si cette commande est utilisé sur un noeud qui n’est pas le dernier à s’être arrêté, le démarrage du service de MariaDB server va échouer et l’erreur suivante sera dans les logs :

[ERROR] WSREP: It may not be safe to bootstrap the cluster from this node. It was not the last one to leave the cluster and may not contain all the updates. To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Si la commande systemctl start mariadb.service est utilisée alors que le cluster n’a pas été initialisé, le démarrage du service échouera en indiquant dans les logs qu’il n’arrive pas à se connecter aux autres noeuds du cluster.

Une fois le cluster initialisé à l'aide de la commande galera_new_cluster, il est possible de (re-)démarrer le service de MariaDB sur les autres serveurs:

systemctl start mariadb.service

Le cluster sera alors reformé.

HAProxy

Lorsque le cluster MariaDB est en place, il est nécessaire, sur chacun des frontaux, de mettre en place un service HAProxy. Ce service permettra de distribuer les requêtes sur un des serveurs de base de données.

L’ensemble des actions présentées ci-après est à faire exclusivement sur les frontaux.

Installation

Le paquet HaProxy est présent dans les dépôts de Debian :

apt-get install haproxy --no-install-recommends

Configuration

Le fichier de configuration haproxy.cfg à modifier se trouve dans le répertoire /etc/haproxy/. Ajouter les lignes suivantes :

listen galera
    bind 127.0.0.1:3306
    balance roundrobin

    mode tcp
    option tcpka
    option mysql-check user haproxy

    # A dupliquer par le nombre de serveur qui peuvent être requêtés
    server galera-1 192.168.0.253:3306 check weight 1
    server galera-2 192.168.0.252:3306 check weight 1
    server galera-3 192.168.0.251:3306 check weight 1

La directive bind doit écouter sur l’interface locale. Il est fortement déconseillé de faire écouter HAProxy sur l’interface publique !

La directive balance peut être modifiée en :

  • leastconn : se connecte au serveur ayant le moins de connexion. Si tous les serveurs ont la même charge, le mode roundrobin sera utilisé.
  • roundrobin : les serveurs de base de données seront requêtés chacun leur tour.

Comme l'indique le fichier de configuration, un utilisateur sera utilisé par le service haproxy pour vérifier que les membres du cluster MariaDB Galera sont disponibles. L'utilisateur haproxy doit être présent sur le cluster Galera. Taper les commandes suivantes sur l'un des noeuds du cluster :

CREATE USER 'haproxy'@'%';
FLUSH PRIVILEGES;

Redémarrer ensuite HAProxy pour appliquer la nouvelle configuration et ainsi être en mesure d’utiliser le cluster MariaDB Galera :

systemctl restart haproxy.service

Le fichier de log se trouve dans /var/log/haproxy.log. Les logs contiennent les modifications d’états des serveurs de base de données présents dans la configuration d’HAProxy.

Pour tester la connexion sur le serveur web web-1 :

mysql -u <user> -p -h 127.0.0.1

Configuration des sites

La configuration des sites web se fera maintenant en utilisant l'adresse 127.0.0.1.

⚠️ **GitHub.com Fallback** ⚠️