Comment configurer un cluster Galera avec MariaDB 10.1 sur des serveurs Ubuntu 16.04

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 existent en deux configurations générales, active-passive et active-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érations SELECT 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.

Dans ce guide, nous allons configurer un cluster MariaDB Galera actif-actif. À des fins de démonstration, nous allons configurer et tester trois nœuds, le plus petit cluster configurable.

Conditions préalables

Pour suivre, vous aurez besoin de:

Three Ubuntu 16.04 servers, chacun avec un utilisateur non root avec les privilègessudo et un réseau privé, s'il est disponible pour vous.
- Pour obtenir de l'aide lors de la configuration d'un utilisateur avec ces privilèges, suivez notre guideInitial Server Setup with Ubuntu 16.04.
- Pour obtenir de l'aide sur la configuration d'un réseau privé, consultezHow To Set Up And Use DigitalOcean Private Networking.

Une fois que toutes ces conditions préalables sont en place, nous sommes prêts à installer MariaDB.

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

MariaDB 10.1 n'étant pas inclus dans les référentiels Ubuntu par défaut, nous allons commencer par ajouter le référentiel externe Ubuntu géré par le projet MariaDB à nos 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, nous allons ajouter la clé du référentiel MariaDB avec la commandeapt-key, qu'apt utilisera pour vérifier que le package est authentique.

sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

Une fois que nous avons la clé de confiance dans la base de données, nous pouvons ajouter le référentiel. Nous devrons exécuterapt-get update par la suite pour inclure les manifestes de package du nouveau référentiel:

sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://nyc2.mirrors.digitalocean.com/mariadb/repo/10.1/ubuntu xenial main'
sudo apt-get update

[.note] #Note: Vous devez exécuter `update` après avoir ajouté le référentiel. Sinon, vous installerez la version 10.0 à partir des packages Ubuntu, qui ne contiennent pas le package Galera.
#

Une fois les référentiels mis à jour sur les trois serveurs, nous sommes prêts à 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. Par souci de cohérence, nous utilisonsmysql dans ce guide où l'un ou l'autre pourrait fonctionner.

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

À partir de la version 10.1, les packages MariaDB Server et MariaDB Galera Server sont combinés, donc l'installation de `mariadb-server` installera automatiquement Galera et plusieurs dépendances:

sudo apt-get install mariadb-server

Lors de l'installation, vous serez invité à définir un mot de passe pour l'utilisateur administratif de MariaDB. Quoi que vous choisissiez, ce mot de passe root sera écrasé par le mot de passe du premier nœud une fois la réplication commencée.

Nous devrions disposer de tous les éléments nécessaires pour commencer à configurer le cluster, mais comme nous nous fierons àrsync dans les étapes ultérieures, assurons-nous qu'il est installé.

sudo apt-get install rsync

Cela confirmera que la dernière version dersync est déjà disponible ou vous invitera à la mettre à niveau ou à l'installer.

Une fois que nous avons installé MariaDB sur chacun des trois serveurs, nous pouvons commencer la configuration.

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

Chaque nœud du cluster doit avoir une configuration presque identique. De ce fait, nous allons effectuer toute la configuration sur notre 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 pour une fin en.cnf. Nous allons créer un fichier dans ce répertoire avec toutes nos directives spécifiques aux clusters:

sudo nano /etc/mysql/conf.d/galera.cnf

Copiez et collez la configuration suivante dans le fichier. Vous devrez modifier les paramètres surlignés en rouge. Nous expliquerons ce que chaque section signifie ci-dessous.

/etc/mysql/conf.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/lib/galera/libgalera_smm.so

# Galera Cluster Configuration
wsrep_cluster_name="test_cluster"
wsrep_cluster_address="gcomm://first_ip,second_ip,third_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 Cluster ne fonctionnera pas avec MyISAM ou des moteurs de stockage non transactionnels similaires, etmysqld ne doit pas être lié à l’adresse IP de localhost. Vous pouvez en savoir plus sur les paramètres plus en détail sur le Galera Clustersystem configuration page.
The “Galera Provider Configuration” section configure les composants MariaDB qui fournissent une API de réplication WriteSet. Cela signifie Galera dans notre cas, car Galera est un fournisseur wsrep (WriteSet Replication). Nous spécifions 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.
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 vousmust mettez à jourwsrep_cluster_address avec les adresses de vos trois serveurs. Si vos serveurs ont des adresses IP privées, utilisez-les ici.
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 notre configuration initiale, nous utilisonsrsync, car il est couramment disponible et fait ce dont nous avons 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, enregistrez et fermez le fichier.

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

Sur chacun des nœuds restants, ouvrez le fichier de configuration:

sudo nano /etc/mysql/conf.d/galera.cnf

Collez la configuration que vous avez copiée à partir du premier noeud, puis mettez à jour la «Configuration de Galera Node» pour utiliser l'adresse IP ou le nom de domaine pouvant être résolu pour le noeud 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/conf.d/galera.cnf

. . .
# Galera Node Configuration
wsrep_node_address="this_node_ip"
wsrep_node_name="this_node_name"
. . .

Enregistrez et quittez le fichier sur chaque serveur. Nous sommes presque prêts à faire apparaître le cluster, mais avant cela, nous voudrons nous assurer que les ports appropriés sont ouverts.

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

Sur chaque serveur, vérifions l’état du pare-feu:

sudo ufw status

Dans ce cas, seul SSH est autorisé via:

OutputStatus: active

To                         Action      From
--                         ------      ----
OpenSSH                    ALLOW       Anywhere
OpenSSH (v6)               ALLOW       Anywhere (v6)

Puisque seul le trafic ssh est autorisé dans ce cas, nous devrons ajouter des règles pour le trafic MySQL et Galera. Si nous essayions de démarrer le cluster, nous échouerions à cause des règles de pare-feu.

Galera peut utiliser quatre ports:

3306 Pour les connexions client MySQL et le transfert d'instantané d'état qui utilisent la méthode mysqldump.
4567 Pour le trafic de réplication Galera Cluster, la réplication multidiffusion utilise à la fois le transport UDP et le protocole TCP sur ce port.
4568 Pour le transfert progressif d'État.
4444 Pour tous les autres transferts d'instantané d'état.

Dans notre exemple, nous allons ouvrir les quatre ports pendant que nous effectuons notre configuration. Une fois que nous avons confirmé que la réplication fonctionne, nous souhaitons fermer tous les ports que nous n'utilisons pas réellement et limiter le trafic aux seuls serveurs du cluster.

Ouvrez les ports avec la commande suivante:

sudo ufw allow 3306,4567,4568,4444/tcp
sudo ufw allow 4567/udp

[.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. Le guideUFW Essentials: Common Firewall Rules and Commands peut vous aider.
#

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

Pour commencer, nous devons arrêter le service MariaDB en cours d'exécution afin que notre cluster puisse être mis en ligne.

Arrêtez MariaDB sur les trois serveurs:

Utilisez la commande ci-dessous sur les trois serveurs pour arrêter mysql afin que nous puissions les restaurer dans un cluster:

sudo systemctl stop mysql

systemctl n'affiche pas le résultat de toutes les commandes de gestion des services, donc pour être sûrs que nous avons réussi, nous allons utiliser la commande suivante:

sudo systemctl status mysql

Si la dernière ligne ressemble à ce qui suit, la commande a réussi.

Output . . .
Aug 19 02:55:15 galera-01 systemd[1]: Stopped MariaDB database server.

Une fois que nous avons arrêtémysql sur tous les serveurs, nous sommes prêts à continuer.

Affichez le premier nœud:

Pour faire apparaître le premier noeud, nous devons utiliser un script de démarrage spécial. De la façon dont nous avons configuré notre 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 mysql 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

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'"

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

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

Affichez le deuxième nœud:

Débutmysql:

sudo systemctl start mysql

Nous devrions voir la taille de notre cluster augmenter à chaque mise en ligne de chaque nœud:

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

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

Amenez le troisième nœud:

Débutmysql:

sudo systemctl start mysql

Si tout fonctionne bien, la taille du cluster doit être définie sur trois:

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

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

À ce stade, l'ensemble du cluster doit être en ligne et en communication. Avant de tester la réplication, cependant, il reste un détail de configuration à prendre en compte.

[[step-7 -—- configuration-the-debian-maintenance-user]] == Étape 7 - Configuration de l'utilisateur de maintenance Debian

À l’heure actuelle, les serveurs MariaDB d’Ubuntu et de Debian effectuent des opérations de maintenance courante, telles que la rotation des journaux, en tant qu’utilisateur d’entretien spécial. Lorsque nous avons installé MariaDB, les informations d’identification de cet utilisateur ont été générées aléatoirement, stockées dans/etc/mysql/debian.cnf et insérées dans la base de donnéesmysql de MariaDB.

Dès que nous avons mis en place notre cluster, le mot de passe du premier nœud a été répliqué sur les autres nœuds, de sorte que la valeur dedebian.cnf ne correspond plus au mot de passe de la base de données. Cela signifie que tout ce qui utilise le compte de maintenance essaiera de se connecter à la base de données avec le mot de passe contenu dans le fichier de configuration et échouera sur tous les nœuds sauf le premier.

Pour corriger cela, nous allons copier lesdebian.cnf de notre premier nœud sur les nœuds restants.

Copier du premier nœud:

Ouvrez le fichierdebian.cnf avec votre éditeur de texte:

sudo nano /etc/mysql/debian.cnf

Le fichier devrait ressembler à quelque chose comme:

[client]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = 03P8rdlknkXr1upf
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr

Copiez les informations dans votre presse-papiers.

Mettre à jour le deuxième nœud:

Sur votre deuxième noeud, ouvrez le même fichier:

sudo nano /etc/mysql/debian.cnf

Malgré l'avertissement en haut du fichier qui dit «NE PAS TOUCHER!», Nous devons apporter les modifications pour que le cluster fonctionne. Vous pouvez supprimer en toute confiance les informations actuelles et coller le contenu de la configuration du premier nœud. Ils devraient être exactement les mêmes maintenant. Enregistrez et fermez le fichier.

Mettre à jour le troisième nœud:

Sur votre troisième noeud, ouvrez le même fichier:

sudo nano /etc/mysql/debian.cnf

Supprimez les informations actuelles et collez le contenu de la configuration du premier nœud. Enregistrez et fermez le fichier.

Cette inadéquation n’aurait pas affecté notre capacité à tester la réplication, mais il est préférable de s’occuper tôt pour éviter les échecs plus tard.

[.Remarque]##

Note: Une fois que vous avez terminé, vous pouvez tester que le compte de maintenance est en mesure de se connecter en fournissant le mot de passe desdebian.conflocaux comme suit:

sudo cat /etc/mysql/debian.cnf

Copiez le mot de passe de la sortie. Puis connectez-vous àmysql:

mysql -u debian-sys-maint -p

À l'invite, indiquez le mot de passe que vous avez copié. Si vous pouvez vous connecter, tout va bien.

Sinon, vérifiez que le mot de passe dans le fichier est le même que le premier nœud, puis remplacez-le ci-dessous:

update mysql.user set password=PASSWORD('password_from_debian.cnf') where User='debian-sys-maint';

Répéter pour tester les nœuds restants.

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

Nous avons suivi toutes les étapes jusqu'à ce que notre cluster puisse effectuer la réplication d'un nœud vers un autre, appelée réplication active-active ou maître-maître. Voyons si la réplication fonctionne comme prévu.

Écrivez au premier nœud:

Nous commencerons par apporter des modifications à la base de données sur notre premier noeud. Les commandes suivantes créeront une base de données appeléeplayground et une table à l'intérieur de celle-ci 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");'

Nous avons maintenant une valeur dans notre tableau.

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

Ensuite, nous examinerons le deuxième noeud 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 nous avons 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, nous pouvons é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, nous pouvons lire toutes ces données en interrogeant à nouveau le:

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

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

De nouveau, nous pouvons 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");'

Lisez sur le premier noeud:

De retour sur le premier noeud, nous pouvons vérifier que nos données sont disponibles partout:

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

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

Nous avons testé que nous pouvons écrire sur tous les nœuds et que la réplication est effectuée correctement.

Conclusion

À ce stade, un cluster de test Galera à trois nœuds opérationnel doit être 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 oeil à certains desother state snapshot transfer (sst) agentscomme «xtrabackup» qui vous permet 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.

Enfin, si les membres de votre cluster ne sont pas sur un réseau privé, vous devrez également configurerSSL pour protéger vos données lors de leur déplacement entre les serveurs.

TOC