→ retour au menu des bases de données relationnelles

→ retour au menu de la Haute disponibilité

But

MariaDB possède une fonctionnalité qui permet qu'il travaille en cluster. Celle-ci est dénommée Galera. Cette fonctionnalité permet à plusieurs processus de MariaDB s'exécutant chacun sur des machines différentes et connectés à un réseau de travailler de concert; toute modification effectuée sur une des machine est répercutée sur les autres machines.

Matériel et adressage IP

Dans notre exemple, nous utilisons cinq serveurs. Le schéma ci-dessous nous montre l'adressage IP et le nom de ces trois machines.

Les machines "sv1.home.dom", "sv2.home.dom", "sv3.home.dom" et "sv4.home.dom" vont exécuter chacune le service MariaDB ; la machine "sv0.home.dom" va exécuter le service Garb que nous verrons par la suite. L'ensemble de ces cinq machines constitue le cluster.

Prérequis

Sur les quatre premières machines, MariaDB doit être installé comme décrit dans l'article sur MariaDB: serveur de base de données. Attention: Ce service ne doit pas être activé!!!

Fichier "hosts"

Sur chaque machine du cluster, on ajoute un nom aux différentes adresses réseaux. On le fait en local dans le fichier "/etc/hosts" suivant le schéma ci-dessus. Son contenu devient:

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
 
192.168.1.71 sv0.home.dom
192.168.1.71 sv1.home.dom
192.168.1.72 sv2.home.dom
192.168.1.71 sv3.home.dom
192.168.1.71 sv4.home.dom
 
# serveur mail
192.168.1.110 servermail.home.dom home.dom

Installation

La paquet de MariaDB Server doit être installé sur toutes les machines du cluster. Les dépendances nécessaires sont installées dans la foulée.

dnf install mariadb-server

Enfin on installe le paquet qui permet le clustering.

dnf install mariadb-server-galera

Le paquet Rsync doit être installé aussi sur toutes les machines du cluster:

dnf install rsync

Il permet de synchroniser la base de données qui démarre à partir une des occurrences du cluster de MariaDB active.

Configuration de MariaDB server

Comme expliqué dans l'article sur MariaDB: serveur de base de données, nous placerons les fichiers de la base de données dans le répertoire "/produc/mysql". Il faut créer ce répertoire et en donner la propriété et les privilèges à l'utilisateur "mysql":

mkdir /produc/mysql
chown -R mysql:mysql /produc/mysql
chmod -R 660 /produc/mysql

En conséquence, le fichier de configuration du serveur "/etc/my.cnf.d/mariadb-server.cnf" est à adapter; on modifie l'option suivante:

datadir=/produc/mysql

Cette configuration est à faire sur les quatre machines qui vont accueillir le service "mariadb.service".

Configuration de Galera

On passe à la configuration du cluster. Elle se trouve dans le fichier "/etc/my.cnf.d/galera.cnf".

Voici son contenu adapté à nos besoins:

[mysqld]
innodb_force_primary_key = 1
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0
wsrep_on = ON
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_cluster_name="Home_cluster"
wsrep_cluster_address = "gcomm://192.168.1.70,192.168.1.71,192.168.1.72,192.168.1.73,192.168.1.74"
#wsrep_node_address="192.168.1.71"
wsrep_slave_threads=1
wsrep_certify_nonPK=1
wsrep_max_ws_rows=0
wsrep_max_ws_size=2147483647
wsrep_debug=0
wsrep_convert_LOCK_to_trx=0
wsrep_retry_autocommit=1
wsrep_auto_increment_control=1
wsrep_drupal_282555_workaround=0
wsrep_causal_reads=0
wsrep_notify_cmd=/disk1/mysql.bat/mysql.bat
wsrep_sst_method=rsync
wsrep_sst_auth=root:

Les options modifiées sont mises en gras. Les autres options sont déjà contenues dans le fichier de configuration.

Explications de quelques options importantes:

default-storage-engine=innodb : Il est nécessaire que les différents schémas utilisent le moteur Innodb.
innodb_force_primary_key=1 : Il est fortement conseillé que toute table aie une clé primaire afin d'éviter la prolifération d'enregistrements en doublon inappropriés.
wsrep_on=ON ou wsrep_on=1 : Il permet l'activation du mode cluster.
wsrep_cluster_name="Home_cluster" : On donne un nom identifiant à notre cluster. Il est personnalisable.
wsrep_cluster_address="gcomm://192.168.1.70,192.168.1.71,192.168.1.72,192.168.1.73,192.168.1.74" : Cette option est primordiale. Elle définit l'ensemble des machines du cluster (service Garb compris). On y retrouve les adresses IP de nos cinq machines.
wsrep_notify_cmd=/produc/mysql.bat/mysql.bat : Cette option est facultative. Elle permet d'effectuer une action exécutée par le script défini à tout changement d'état du cluster reçu par la machine locale. Nous l'utiliserons par la suite pour être averti par mail en cas de connexion ou déconnexion d'un membre du cluster. Evidemment il faut que le service de messagerie par exemple Postfix soit activé.
wsrep_node_address="192.168.1.71" : Cette option est facultative. Elle peut être nécessaire si la machine a plusieurs interfaces réseaux. Elle correspond à l'adresse IP de la machine concernée; dans notre exemple, elle est contenue dans le fichier de configuration de la machine "sv1.home.dom".

Cette configuration est à faire sur les quatre machines qui vont accueillir le service "mariadb.service".

Utilisation de Garb

Le cluster doit toujours être constitué d'un nombre impaire de machines car s'il était en nombre pair, deux groupes séparés d'un nombre égal de machines peuvent se constituer suite par exemple à des coupures réseaux. Il n'y aurait alors de de groupe majoritaire et chaque groupe pourrait évoluer séparément avec des bases de données ayant un contenu différents (Split-Brain). La présence d'un nombre pair de bases de données MariaDB peuvent se justifier pour une question de disponibilité de matériel ou d'utilisation finale.

Dans ce cas d'un nombre pair, il faut ajouter une composante additionnelle. Cette composante est le service Garb "garbd.service". Il participe aux échanges entre membres du cluster mais ne stocke aucune données; il n'y a aucun base de données présente. Si nous avons un nombre impaire de base de données Mariadb, le service Garb n'est pas nécessaire.

Configuration de Garb

La configuration de Garb se trouve dans le fichier "/etc/sysconfig/garb".

Voici son contenu:

GALERA_NODES="192.168.1.70,192.168.1.71,192.168.1.72,192.168.1.73,192.168.1.74"
GALERA_GROUP="Home_cluster"
LOG_FILE="/var/log/garb/garb.log"

On y retrouve deux des options définies dans le fichier de configuration de Galera "/etc/my.cnf.d/galera.cnf".

Les options suivantes:

GALERA_NODES correspond au paramètre "wsrep_cluster_address"
GALERA_GROUP correspond au paramètre "wsrep_cluster_name"

On a défini l'emplacement d'un fichier journal. Mais le répertoire concerné n'existe pas; il faut le créer et lui donner la propriété à l'utilisateur "garb" qui lance le service "garbd.service":

mkdir /var/log/garb
chown -R garb:garb /var/log/garb

Dans le fichier de configuration par défaut, il existe l'option "WORK_DIR". Ne l'utilisez pas sinon le service entrera en erreur et ne se lancera pas; l'argument lié n'existe pas pour le processus "garbd". Or ce paramètre est utile si pas nécessaire pour pouvoir localiser le fichier d'état du cluster localement. Il faut donc trouver une astuce. Cette astuce passe par ajouter un option à Systemd.

Nous créons le répertoire "garbd.service.d" dans le répertoire "/etc/systemd.system":

mkdir garbd.service.d

Dans ce répertoire, on crée un fichier qui permet d'ajouter une option définissant le répertoire de travail du service "garbd.service"; On nomme ce fichier "workdir.conf":

[Service]
WorkingDirectory=/produc/garb

Comme on a modifié le paramétrage de Systemd, il faut le recharger:

systemctl daemon-reload

Il faut maintenant créer ce répertoire et lui donner la propriété à l'utilisateur "garb" qui lance le service "garbd.service":

mkdir /produc/garb
chown -R garb:garb /produc/garb

Cette configuration est à faire sur la machine "sv0.home.dom" qui va accueillir le service "garbd.service".

Activation des services

Au contraire de ce qu'on fait habituellement, les services "mariadb.service" et "garbd.service" ne devront jamais être activés. Car dans le cas où toutes les machines sont arrêtées, le cluster n'existe plus. Il faut donc toujours réinitialiser le cluster sur la machine où le dernier service "mariadb.service" a été arrêté en dernier lieu et donc qui a la version de la base de données la plus récente. Dès que le cluster a été lancé, on peut alors lancer les services "mariadb.service" ou "garbd.service" sur les autres machines.

Configurer le mur de feu ou FireWall

MariaDB écoute sur le port TCP 3306 comme traité dans l'article sur MariaDB: serveur de base de données. Nous n'y reviendrons pas.

Par contre, la fonctionnalité Galera (Garb comprise) utilise toute une série de ports qu'il faut sécuriser.

le port TCP 4444 permet au programme Rsync la synchronisation au démarrage
les ports TCP et UDP 4567 permettent la réplication en cours d'utilisation entre les bases de données
Le port TCP 4568 permet le transfert incrémental de l'état afin de rattraper son retard vis-à-vis de ses collègues

Ces transferts de passent exclusivement entre les machines du cluster.

Pour le FireWall Iptables, on ajoute les règles suivantes sur toutes les machines du cluster:

-A INPUT -p tcp -m tcp --dport 4444 -m iprange --src-range 192.168.1.70-192.168.1.74 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4567 -m iprange --src-range 192.168.1.70-192.168.1.74 -j ACCEPT
-A INPUT -p udp -m udp --dport 4567 -m iprange --src-range 192.168.1.70-192.168.1.74 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4568 -m iprange --src-range 192.168.1.70-192.168.1.74 -j ACCEPT

Initialisation du cluster

La première étape est l'initialisation du cluster.

On choisit une des quatre machines devant héberger le service MariaDB. Sur cette machine on lance une première fois le service "mariadb.service":

systemctl start mariadb.service

et on le sécurise avec la commande:

mysql_secure_installation

On peut maintenant arrêter ce service:

systemctl stop mariadb.service

Il est inutile de lancer le service MariaDB sur les trois autres machines car la base de données résultante sera écrasée, perdue. On ne lance pas le service Garb car le cluster n'existe pas encore; il entrerait en erreur.

On lance le cluster avec la commande:

galera_new_cluster

En parcourant la liste des processus, on peut remarquer que le services "mariadb.service" est lancé. Pour l'arrêter, on peut utiliser la commande classique:

systemctl stop mariadb.service

Lancement du cluster