« LINUX:Galera - Cluster de MariaDB » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 18 : | Ligne 18 : | ||
=Prérequis= | =Prérequis= | ||
Sur les quatre premières machines, MariaDB doit être installé comme décrit dans l'article sur [[LINUX:MariaDB|MariaDB: serveur de base de données]]. | Sur les quatre premières machines, MariaDB doit être installé comme décrit dans l'article sur [[LINUX:MariaDB|MariaDB: serveur de base de données]]. Attention: ce service ne doit pas être activé!!! | ||
| Ligne 47 : | Ligne 47 : | ||
Il permet de synchroniser la base de données qui démarre à partir une des occurrences du cluster de MariaDB active. | 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 [[LINUX:MariaDB|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. | |||
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". | |||
=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. | |||
Version du 9 avril 2023 à 11:35
→ 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 dervice 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.
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".
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
→ retour au menu des bases de données relationnelles
→ retour au menu de la Haute disponibilité