Comment configurer un cluster Galera avec MariaDB sur des serveurs CentOS 7

L'auteur a sélectionné lesFree and Open Source Fund pour recevoir un don dans le cadre du programmeWrite for DOnations.

introduction

Le clustering ajoute une haute disponibilité à votre base de données en distribuant les modifications à différents serveurs. En cas de défaillance d’une des instances, d’autres sont rapidement disponibles pour continuer à servir.

Les clusters sont disponibles en deux configurations générales,active-passive etactive-active. Dans les clusters actifs-passifs, toutes les écritures sont effectuées sur un seul serveur actif, puis copiées sur un ou plusieurs serveurs passifs qui ne prendront le relais que dans le cas d'une défaillance du serveur actif. Certains clusters actifs-passifs autorisent également les opérationsSELECT sur des nœuds passifs. Dans un cluster actif-actif, chaque nœud est en lecture-écriture et une modification apportée à l'un d'entre eux est répliquée pour tous.

MariaDB est un système de base de données relationnelle open source entièrement compatible avec le système SGBDR MySQL populaire. Vous pouvez lire la documentation officielle de MariaDB à cepage. Galera est une solution de mise en cluster de bases de données qui vous permet de configurer des clusters multimaître à l'aide de la réplication synchrone. Galera gère automatiquement la synchronisation des données de différents nœuds tout en vous permettant d'envoyer des requêtes de lecture et d'écriture à l'un des nœuds du cluster. Vous pouvez en savoir plus sur Galera sur le site officieldocumentation page.

Dans ce guide, vous allez configurer un cluster MariaDB Galera actif-actif. À des fins de démonstration, vous allez configurer et tester trois droplets CentOS 7 qui agiront en tant que nœuds dans le cluster. C'est le plus petit cluster configurable.

Conditions préalables

Pour suivre, vous aurez besoin d'unDigitalOcean account, en plus des éléments suivants:

Bien que les étapes de ce didacticiel aient été écrites et testées sur les gobelets DigitalOcean, nombre d'entre elles devraient également s'appliquer aux serveurs non-DigitalOcean avec la mise en réseau privée activée.

[[step-1 -—- ajoutant-the-mariadb-repositories-to-all-servers]] == Étape 1 - Ajout des référentiels MariaDB à tous les serveurs

Au cours de cette étape, vous allez ajouter les référentiels de packages MariaDB appropriés à chacun de vos trois serveurs afin de pouvoir installer la bonne version de MariaDB utilisée dans ce didacticiel. Une fois les référentiels mis à jour sur les trois serveurs, vous serez prêt à installer MariaDB.

Une chose à noter à propos de MariaDB est qu'elle a été créée en tant que remplacement de MySQL, donc dans de nombreux fichiers de configuration et scripts de démarrage, vous verrezmysql plutôt quemariadb. Dans de nombreux cas, ceux-ci sont interchangeables. Pour des raisons de cohérence, nous utiliseronsmariadb dans ce guide où l'un ou l'autre pourrait fonctionner.

Dans ce didacticiel, vous utiliserezMariaDB version 10.4. Comme cette version n’est pas incluse dans les référentiels CentOS par défaut, vous commencerez par ajouter le référentiel CentOS externe géré par le projet MariaDB à vos trois serveurs.

[.note] #Note: MariaDB est un fournisseur très respecté, mais tous les référentiels externes ne sont pas fiables. Veillez à installer uniquement à partir de sources fiables.
#

Tout d'abord, vous allez ajouter la clé de référentiel MariaDB en créant un fichier de référentiel avec un éditeur de texte. Ce tutoriel utiliseravi:

sudo vi /etc/yum.repos.d/mariadb.repo

Ensuite, ajoutez le contenu suivant au fichier en appuyant suri pour passer en mode insertion, puis en ajoutant ce qui suit:

/etc/yum.repos.d/mariadb.repo

[mariadb]
name = MariaDB
baseurl = http://yum.mariadb.org/10.4/centos7-amd64
gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB
gpgcheck=1

Appuyez sur la toucheesc pour revenir au mode normal, puis tapez:wq pour enregistrer et quitter le fichier. Si vous souhaitez en savoir plus sur l'éditeur de textevi et son prédécesseurvim, jetez un œil à notre tutoriel surInstalling and Using the Vim Text Editor on a Cloud Server.

Une fois que vous avez créé le fichier de référentiel, activez-le avec la commande suivante:

sudo yum makecache --disablerepo='*' --enablerepo='mariadb'

La commandemakecache met en cache les métadonnées du référentiel afin que le gestionnaire de packages puisse installer MariaDB, avec--disablerepo et--enablerepo ciblant la commande vers le fichier repomariadb que vous venez de créer.

Vous recevrez le résultat suivant:

OutputLoaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
mariadb                                                                                                                                                                              | 2.9 kB  00:00:00
(1/3): mariadb/primary_db                                                                                                                                                            |  43 kB  00:00:00
(2/3): mariadb/other_db                                                                                                                                                              | 8.3 kB  00:00:00
(3/3): mariadb/filelists_db                                                                                                                                                          | 238 kB  00:00:00
Metadata Cache Created

Une fois que vous avez activé le référentiel sur votre premier serveur, répétez l'opération pour vos deuxième et troisième serveurs.

Maintenant que vous avez ajouté le référentiel de paquets sur vos trois serveurs, vous êtes prêt à installer MariaDB dans la section suivante.

[[step-2 -—- Installing-mariadb-on-all-servers]] == Étape 2 - Installation de MariaDB sur tous les serveurs

Dans cette étape, vous allez installer les packages MariaDB réels sur vos trois serveurs.

À partir de la version10.1, les packages MariaDB Server et MariaDB Galera Server sont combinés, donc l'installation deMariaDB-server installera automatiquement Galera et plusieurs dépendances:

sudo yum install MariaDB-server MariaDB-client

Vous serez invité à confirmer si vous souhaitez procéder à l'installation. Entrezyes pour continuer l'installation. Vous serez ensuite invité à accepter la clé GPG qui authentifie le package MariaDB. Entrez à nouveauyes.

Une fois l'installation terminée, démarrez le servicemariadb en exécutant:

sudo systemctl start mariadb

Activez le démarrage automatique du servicemariadb au démarrage en exécutant:

sudo systemctl enable mariadb

À partir de la version10.4 de MariaDB, l'utilisateur MariaDB deroot n'a pas de mot de passe par défaut. Pour définir un mot de passe pour l'utilisateurroot, commencez par vous connecter à MariaDB:

sudo mysql -uroot

Une fois que vous êtes dans le shell MariaDB, modifiez le mot de passe en exécutant l'instruction suivante, en remplaçantyour_password par le mot de passe souhaité:

set password = password("your_password");

Vous verrez la sortie suivante indiquant que le mot de passe a été défini correctement:

OutputQuery OK, 0 rows affected (0.001 sec)

Quittez le shell MariaDB en exécutant la commande suivante:

quit;

Si vous souhaitez en savoir plus sur SQL ou avoir besoin d'un rappel rapide, consultez nosMySQL tutorial.

Vous disposez maintenant de tous les éléments nécessaires pour commencer à configurer le cluster, mais puisque vous vous fiez àrsync etpolicycoreutils-python dans les étapes ultérieures pour synchroniser les serveurs et contrôler Linux Security-Enhanced (SELinux) , assurez-vous qu'ils sont installés avant de continuer:

sudo yum install rsync policycoreutils-python

Cela confirmera que les dernières versions dersync etpolicycoreutils-python sont déjà disponibles ou vous inviteront à les mettre à niveau ou à les installer.

Une fois ces étapes terminées, répétez-les pour vos deux autres serveurs.

Maintenant que vous avez installé MariaDB avec succès sur chacun des trois serveurs, vous pouvez passer à l'étape de configuration de la section suivante.

[[step-3 -—- configuration-the-first-node]] == Étape 3 - Configuration du premier nœud

Dans cette étape, vous allez configurer votre premier noeud Galera. Chaque nœud du cluster doit avoir une configuration presque identique. De ce fait, vous allez effectuer toute la configuration sur votre première machine, puis la copier sur les autres nœuds.

Par défaut, MariaDB est configuré pour vérifier le répertoire/etc/mysql/conf.d pour obtenir des paramètres de configuration supplémentaires à partir des fichiers se terminant par.cnf. Créez un fichier dans ce répertoire avec toutes vos directives spécifiques au cluster:

sudo vi /etc/my.cnf.d/galera.cnf

Ajoutez la configuration suivante dans le fichier. La configuration spécifie différentes options de cluster, des détails sur le serveur actuel et les autres serveurs du cluster, ainsi que des paramètres liés à la réplication. Notez que les adresses IP de la configuration sont les adresses privées de vos serveurs respectifs. remplacez les lignes en surbrillance par les adresses IP appropriées:

/etc/my.cnf.d/galera.cnf

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_on=ON
wsrep_provider=/usr/lib64/galera-4/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://First_Node_IP,Second_Node_IP,Third_Node_IP"

# Galera Synchronization Configuration
wsrep_sst_method=rsync

# Galera Node Configuration
wsrep_node_address="This_Node_IP"
wsrep_node_name="This_Node_Name"
  • The first section modifie ou réaffirme les paramètres MariaDB / MySQL qui permettront au cluster de fonctionner correctement. Par exemple, Galera ne fonctionnera pas avec MyISAM ou des moteurs de stockage non transactionnels similaires, etmysqld ne doit pas être lié à l’adresse IP delocalhost.

  • The “Galera Provider Configuration” section configure les composants MariaDB qui fournissent une API de réplication WriteSet. Cela signifie Galera dans votre cas, puisque Galera est un fournisseurwsrep (WriteSet Replication). Vous spécifiez les paramètres généraux pour configurer l'environnement de réplication initial. Cela ne nécessite aucune personnalisation, mais vous pouvez en savoir plus surGalera configuration options here.

  • The “Galera Cluster Configuration” section définit le cluster, identifiant les membres du cluster par adresse IP ou nom de domaine résoluble et créant un nom pour le cluster afin de garantir que les membres rejoignent le groupe approprié. Vous pouvez changer leswsrep_cluster_name en quelque chose de plus significatif quetest_cluster ou le laisser tel quel, mais vous devez mettre à jourwsrep_cluster_address avec les adresses IP privées de vos trois serveurs.

  • The “Galera Synchronization Configuration” section définit comment le cluster communiquera et synchronisera les données entre les membres. Ceci est utilisé uniquement pour le transfert d'état qui se produit lorsqu'un nœud est mis en ligne. Pour votre configuration initiale, vous utilisezrsync, car il est couramment disponible et fait ce dont vous aurez besoin pour le moment.

  • The “Galera Node Configuration” section clarifie l'adresse IP et le nom du serveur actuel. Cela s'avère utile lorsque vous essayez de diagnostiquer des problèmes dans les journaux et de référencer chaque serveur de plusieurs manières. Leswsrep_node_address doivent correspondre à l’adresse de la machine sur laquelle vous vous trouvez, mais vous pouvez choisir le nom de votre choix pour vous aider à identifier le nœud dans les fichiers journaux.

Lorsque vous êtes satisfait du fichier de configuration du cluster, copiez le contenu dans le Presse-papiers, puis enregistrez et fermez le fichier.

Maintenant que vous avez configuré votre premier nœud avec succès, vous pouvez passer à la configuration des nœuds restants dans la section suivante.

[[step-4 -—- configurer-les-nœuds-restants]] == Étape 4 - Configurer les nœuds restants

Dans cette étape, vous allez configurer les deux nœuds restants. Sur votre deuxième noeud, ouvrez le fichier de configuration:

sudo vi /etc/mysql/my.cnf.d/galera.cnf

Collez la configuration que vous avez copiée à partir du premier nœud, puis mettez à jour lesGalera Node Configuration pour utiliser l’adresse IP ou le nom de domaine résoluble pour le nœud spécifique que vous configurez. Enfin, mettez à jour son nom, que vous pouvez définir comme bon vous semble pour identifier le nœud dans vos fichiers journaux:

/etc/mysql/my.cnf.d/galera.cnf

. . .
# Galera Node Configuration
wsrep_node_address="This_Node_IP"
wsrep_node_name="This_Node_Name"
. . .

Enregistrez et quittez le fichier.

Une fois ces étapes terminées, répétez-les sur le troisième nœud.

Avec Galera configuré sur tous vos nœuds, vous êtes presque prêt à afficher le cluster. Mais avant cela, assurez-vous que les ports appropriés sont ouverts sur votre pare-feu et qu’une stratégie SELinux a été créée pour Galera.

[[step-5 -—- opening-the-firewall-on-every-server]] == Étape 5 - Ouverture du pare-feu sur chaque serveur

Dans cette étape, vous allez configurer votre pare-feu pour que les ports requis pour la communication entre nœuds soient ouverts.

Sur chaque serveur, vérifiez l'état du pare-feu que vous avez configuré dans la section Prérequis en exécutant:

sudo firewall-cmd --list-all

Dans ce cas, seul le trafic SSH, DHCP, HTTP et HTTPS est autorisé via:

Outputpublic
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: ssh dhcpv6-client http https
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Si vous tentiez de démarrer le cluster maintenant, cela échouerait car le pare-feu bloquerait les connexions entre les nœuds. Pour résoudre ce problème, ajoutez des règles permettant le trafic de MariaDB et Galera.

Galera peut utiliser quatre ports:

  • 3306 Pour les connexions client MariaDB et State Snapshot Transfer utilisant la méthodemysqldump.

  • 4567 Pour le trafic de réplication de Galera Cluster. La réplication multidiffusion utilise à la fois le transport UDP et TCP sur ce port.

  • 4568 PourIncremental State Transfers, ou IST, processus par lequel un état manquant est reçu par les autres nœuds du cluster.

  • 4444 Pour tous les autresState Snapshot Transfers, ou SST, le mécanisme par lequel un nœud de jointure obtient son état et ses données d'un nœud donateur.

Dans cet exemple, vous allez ouvrir les quatre ports pendant votre configuration. Une fois que vous avez vérifié que la réplication fonctionne, vous souhaitez fermer tous les ports que vous n'utilisez pas réellement et limiter le trafic aux seuls serveurs du cluster.

Ouvrez les ports avec les commandes suivantes:

sudo firewall-cmd --permanent --zone=public --add-port=3306/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4567/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4568/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4444/tcp
sudo firewall-cmd --permanent --zone=public --add-port=4567/udp

En utilisant ici--zone=public et--add-port=,firewall-cmd ouvre ces ports au trafic public. --permanent garantit que ces règles persistent.

[.note] #Note: En fonction de ce qui est en cours d'exécution sur vos serveurs, vous souhaiterez peut-être restreindre l'accès immédiatement. Pour en savoir plus sur l'utilisation de FirewallD, consultez notre tutorielHow To Set Up a Firewall Using FirewallD on CentOS 7.
#

Maintenant, ajoutez chaque serveur à la zonepublic en exécutant les commandes suivantes, en remplaçant le texte en surbrillance par les adresses IP privées respectives de vos nœuds:

sudo firewall-cmd --permanent --zone=public --add-source=galera-node-1-ip/32
sudo firewall-cmd --permanent --zone=public --add-source=galera-node-2-ip/32
sudo firewall-cmd --permanent --zone=public --add-source=galera-node-3-ip/32

Rechargez le pare-feu pour appliquer les modifications:

sudo firewall-cmd --reload

Après avoir configuré votre pare-feu sur le premier nœud, créez les mêmes paramètres de pare-feu sur les deuxième et troisième nœuds.

Maintenant que vous avez configuré les pare-feu avec succès, vous êtes prêt à créer une stratégie SELinux à l’étape suivante.

[[step-6 -—- creating-a-selinux-policy]] == Étape 6 - Création d'une stratégie SELinux

Dans cette section, vous allez créer une stratégie SELinux qui permettra à tous les nœuds du cluster de communiquer entre eux et d’effectuer des opérations de cluster.

SELinux est un module du noyau Linux qui améliore la sécurité des systèmes d'exploitation grâce à sa prise en charge du contrôle d'accès et des politiques de contrôle d'accès obligatoires. Il est activé par défaut sur CentOS 7 et empêche le démon MariaDB d’exécuter de nombreuses activités.

Afin de créer la stratégie, vous allez effectuer diverses activités sur le cluster avec le mode SELinux défini sur Permissive pour MySQL. Vous allez ensuite créer une stratégie à partir des événements enregistrés et définir le mode SELinux pour qu'il soit appliqué une fois la stratégie installée.

Tout d'abord, autorisez l'accès aux ports pertinents en exécutant les commandes suivantes sur les trois serveurs:

sudo semanage port -a -t mysqld_port_t -p tcp 4567
sudo semanage port -a -t mysqld_port_t -p udp 4567
sudo semanage port -a -t mysqld_port_t -p tcp 4568
sudo semanage port -a -t mysqld_port_t -p tcp 4444

[.note] #Note: Vous pouvez recevoir unValueError lorsque vous autorisez l'accès à certains de ces ports. Cela signifie que le statut SELinux de ce port a déjà été défini, ce qui dans ce cas n'affectera pas le processus de ce tutoriel.
#

Dans ces commandes, vous utilisez l'outil de gestion SELinuxsemanage avec l'indicateur-a pour ajouter des ports spécifiés et pour ignorer le serveur de base de données.

Ensuite, exécutez la commande suivante sur les trois serveurs, qui définit temporairement le domaine MySQL SELinux en mode permissif.

sudo semanage permissive -a mysqld_t

Cette commande peut durer une minute et n’affichera aucune sortie.

Ensuite, arrêtez le serveur de base de données sur tous les nœuds afin de pouvoir amorcer le cluster de base de données avec des stratégies SELinux partagées. Pour ce faire, exécutez la commande suivante sur les trois nœuds:

sudo systemctl stop mariadb

Maintenant, amorcez le cluster pour générer des événements de communication inter-nœuds qui seront ajoutés à la stratégie SELinux. Sur le premier nœud, amorcez le cluster en exécutant:

sudo galera_new_cluster

Créez une base de données et une table dans le but spécifique de consigner les événements SST en exécutant les opérations suivantes sur le premier nœud:

mysql -u root -p -e 'CREATE DATABASE selinux;
CREATE TABLE selinux.selinux_policy (id INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(id));
INSERT INTO selinux.selinux_policy VALUES ();'

Maintenant démarrez le serveur sur le deuxième noeud:

sudo systemctl start mariadb

Ensuite, faites la même chose sur le troisième noeud:

sudo systemctl start mariadb

Vous ne verrez aucune sortie pour les commandes précédentes. Pour générer des événements IST, exécutez les opérations suivantes sur les trois serveurs:

mysql -u root -p -e 'INSERT INTO selinux.selinux_policy VALUES ();'

Créez et activez maintenant la stratégie SELinux en exécutant les commandes suivantes sur les trois serveurs:

sudo grep mysql /var/log/audit/audit.log | sudo audit2allow -M Galera

Cette première commande recherche les événements générés dans le fichieraudit.log et les dirige vers un module nomméGalera.pp généré par l'outilaudit2allow. Cela se traduira par la sortie suivante:

Output******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i Galera.pp

Ensuite, suivez les instructions dans la sortie et utilisez la commande suivante pour installer le module généré:

sudo semodule -i Galera.pp

Maintenant que la stratégie est active, désactivez le mode permissif pour le serveur MariaDB:

sudo semanage permissive -d mysqld_t

Maintenant que vous avez créé et activé une règle SELinux, vous êtes prêt à démarrer le cluster dans la section suivante.

[[step-7 -—- starting-the-cluster]] == Étape 7 - Démarrage du cluster

Dans cette étape, vous allez démarrer votre cluster MariaDB. Pour commencer, vous devez arrêter le service MariaDB en cours d'exécution afin de pouvoir mettre votre cluster en ligne.

Arrêtez MariaDB sur les trois serveurs

Lors de l'arrêt du service MariaDB, il est important d'exécuter cette action sur vos serveurs dans un ordre spécifique. Cette séquence d'arrêt garantit que le premier nœud sera en mesure d'amorcer le cluster en toute sécurité lors de son démarrage.

Tout d'abord, exécutez la commande suivante sur le troisième nœud:

sudo systemctl stop mariadb

Ensuite, arrêtez le service sur le deuxième noeud:

sudo systemctl stop mariadb

Enfin, arrêtez le service sur le premier noeud:

sudo systemctl stop mariadb

systemctl n'affiche pas le résultat de toutes les commandes de gestion de service, donc pour être sûr que vous avez réussi, utilisez la commande suivante sur chacun de vos serveurs:

sudo systemctl status mariadb

La dernière ligne ressemblera à ceci:

Output. . .
Apr 26 03:34:23 galera-node-01 systemd[1]: Stopped MariaDB 10.4.4 database server.

Une fois que vous avez arrêtémariadb sur tous les serveurs, vous êtes prêt à continuer.

Afficher le premier nœud

Pour faire apparaître le premier nœud, vous devez utiliser un script de démarrage spécial. De la manière dont vous avez configuré votre cluster, chaque nœud qui se met en ligne tente de se connecter à au moins un autre nœud spécifié dans son fichiergalera.cnf pour obtenir son état initial. Sans utiliser le scriptgalera_new_cluster qui permet à systemd de passer le paramètre--wsrep-new-cluster, unsystemctl start mariadb normal échouerait car il n'y a aucun nœud en cours d'exécution pour le premier nœud auquel se connecter.

sudo galera_new_cluster

Cette commande n'affiche aucune sortie en cas d'exécution réussie. Lorsque ce script réussit, le nœud est enregistré en tant que partie du cluster et vous pouvez le voir à l'aide de la commande suivante:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

Vous verrez la sortie suivante indiquant qu'il y a un nœud dans le cluster:

Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 1     |
+--------------------+-------+

Sur les nœuds restants, vous pouvez démarrermariadb normalement. Ils rechercheront n'importe quel membre de la liste de grappes en ligne. Ainsi, lorsqu'ils en trouveront une, ils rejoindront la grappe.

Amener le deuxième nœud

Maintenant, vous pouvez faire apparaître le deuxième noeud. Débutmariadb:

sudo systemctl start mariadb

Aucune sortie ne sera affichée lors d'une exécution réussie. Vous verrez la taille de votre cluster augmenter à chaque mise en ligne de chaque nœud:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

La sortie suivante indique que le deuxième nœud a rejoint le cluster et qu'il y a deux nœuds au total.

Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 2     |
+--------------------+-------+

Amener le troisième nœud

Il est maintenant temps de faire apparaître le troisième nœud. Débutmariadb:

sudo systemctl start mariadb

Exécutez la commande suivante pour trouver la taille du cluster:

mysql -u root -p -e "SHOW STATUS LIKE 'wsrep_cluster_size'"

Vous verrez la sortie suivante, qui indique que le troisième nœud a rejoint le cluster et que le nombre total de nœuds dans le cluster est de trois.

Output+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| wsrep_cluster_size | 3     |
+--------------------+-------+

À ce stade, l'ensemble du cluster est en ligne et communique avec succès. Ensuite, vous pouvez vous assurer que la configuration est opérationnelle en testant la réplication dans la section suivante.

[[step-8 -—- testing-replication]] == Étape 8 - Test de la réplication

Vous avez suivi toutes les étapes jusqu'à ce que votre cluster puisse effectuer la réplication d'un nœud vers un autre, appelée réplication active-active. Suivez les étapes suivantes pour tester et voir si la réplication fonctionne comme prévu.

Écrire au premier nœud

Vous commencerez par apporter des modifications à la base de données sur votre premier noeud. Les commandes suivantes créeront une base de données appeléeplayground et une table à l'intérieur de cette base de données appeléeequipment.

mysql -u root -p -e 'CREATE DATABASE playground;
CREATE TABLE playground.equipment ( id INT NOT NULL AUTO_INCREMENT, type VARCHAR(50), quant INT, color VARCHAR(25), PRIMARY KEY(id));
INSERT INTO playground.equipment (type, quant, color) VALUES ("slide", 2, "blue");'

Dans la commande précédente, l'instructionCREATE DATABASE crée une base de données nomméeplayground. L'instructionCREATE crée une table nomméeequipment dans la base de donnéesplayground ayant une colonne d'identifiant auto-incrémentée appeléeid et d'autres colonnes. La colonnetype, la colonnequant et la colonnecolor sont définies pour stocker respectivement le type, la quantité et la couleur de l'équipement. L'instructionINSERT insère une entrée de typeslide, quantité2 et couleurblue.

Vous avez maintenant une valeur dans votre table.

Lire et écrire sur le deuxième nœud

Ensuite, examinez le deuxième nœud pour vérifier que la réplication fonctionne:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Si la réplication fonctionne, les données que vous avez entrées sur le premier nœud seront visibles ici sur le second:

Output+----+-------+-------+-------+
| id | type  | quant | color |
+----+-------+-------+-------+
|  1 | slide |     2 | blue  |
+----+-------+-------+-------+

À partir de ce même nœud, vous pouvez écrire des données sur le cluster:

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("swing", 10, "yellow");'

Lire et écrire sur le troisième nœud

À partir du troisième nœud, vous pouvez lire toutes ces données en interrogeant à nouveau la table:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Vous verrez la sortie suivante montrant les deux lignes:

Output   +----+-------+-------+--------+
   | id | type  | quant | color  |
   +----+-------+-------+--------+
   |  1 | slide |     2 | blue   |
   |  2 | swing |    10 | yellow |
   +----+-------+-------+--------+

De nouveau, vous pouvez ajouter une autre valeur à partir de ce nœud:

mysql -u root -p -e 'INSERT INTO playground.equipment (type, quant, color) VALUES ("seesaw", 3, "green");'

Lire sur le premier nœud

De retour sur le premier noeud, vous pouvez vérifier que vos données sont disponibles partout:

mysql -u root -p -e 'SELECT * FROM playground.equipment;'

Vous verrez la sortie suivante, qui indique que les lignes sont disponibles sur le premier nœud.

Output   +----+--------+-------+--------+
   | id | type   | quant | color  |
   +----+--------+-------+--------+
   |  1 | slide  |     2 | blue   |
   |  2 | swing  |    10 | yellow |
   |  3 | seesaw |     3 | green  |
   +----+--------+-------+--------+

Vous avez vérifié que vous pouvez écrire sur tous les nœuds et que la réplication est correctement effectuée.

Conclusion

À ce stade, vous avez un cluster de test Galera à trois nœuds configuré. Si vous envisagez d’utiliser un cluster Galera en situation de production, il est recommandé de commencer par au moins cinq nœuds.

Avant l'utilisation en production, vous voudrez peut-être jeter un coup d'œil à certains desother state snapshot transfer (SST) agents commeXtraBackup, qui vous permettent de configurer de nouveaux nœuds très rapidement et sans interruptions importantes de vos nœuds actifs. Cela n'affecte pas la réplication réelle, mais constitue un problème lorsque les noeuds sont en cours d'initialisation.

Si vous souhaitez continuer à vous familiariser avec les bases de données SQL, consultez notre article surHow To Manage an SQL Database.

Related