Dans cet article, je vais vous montrer comment configurer un cluster de base de données MySQL avec trois nœuds dans une réplication multi-maître. La réplication multimaître permet l'écriture d'enregistrements dans chaque nœud, donc si un nœud échoue, nous pouvons travailler sur l'autre comme si de rien n'était.
La documentation officielle de Percona est disponible sur le site officiel https://www.percona.com/
Tout d'abord, pourquoi choisit-on trois nœuds et pas seulement deux ? Dans n'importe quel cluster, le nombre de nœuds doit être impair. Ainsi, en cas de déconnexion d'un nœud, nous supposons que le groupe de serveurs le plus élevé contient les nouvelles données et doit être répliqué sur le nœud inférieur pour éviter la perte de données. Ceci est uniquement lié à la résolution des conflits dans la réplication des données, nous ne perdrons pas les données écrites uniquement sur le nœud déconnecté.
Ceci est utilisé pour éviter une circonstance appelée split brain , dans lequel nous ne pouvons pas choisir automatiquement quel nœud contient des données correctes. Pensez par exemple à un cluster à 2 nœuds où les deux nœuds sont déconnectés l'un de l'autre et le même enregistrement est écrit sur les deux nœuds :qui gagne lorsqu'ils reviennent en ligne ? Nous ne savons pas, donc le cerveau partagé se produit, et nous devons décider manuellement quel enregistrement est le bon.
Le nombre de nœuds nécessaires pour déterminer quelle partie du cluster contient les bonnes données s'appelle QUORUM, dans notre cas, le quorum sera de 2. Nous avons donc besoin que 2 serveurs soient toujours connectés l'un à l'autre. Dans le cas où les trois nœuds tomberaient en panne, nous avons un split brain et nous devons décider manuellement quel serveur doit passer en mode bootstrap, c'est la procédure pour déterminer quel sera le serveur principal à reprendre à partir du split brain.
Configuration du cluster Percona XtraDB sur Debian 8
Ce didacticiel décrit comment installer et configurer trois nœuds de cluster Percona XtraDB sur des serveurs Debian 8. Nous utiliserons les packages des référentiels Percona.
- serveur 1
- Nom d'hôte :mysql1.local.vm
- Adresse IP :192.168.152.100
- Nœud 2
- Nom d'hôte : mysql2.local.vm
- Adresse IP :192.168.152.110
- Nœud 3
- Nom d'hôte : mysql3.local.vm
- Adresse IP :192.168.152.120
Sur chaque hôte, modifiez le fichier /etc/hosts comme suit pour vous assurer que DNS fonctionnera correctement.
127.0.0.1 localhost
192.168.152.100 mysql1.local.vm mysql1
192.168.152.110 mysql2.local.vm mysql2
192.168.152.120 mysql3.local.vm mysql3
# Les lignes suivantes sont souhaitables pour les hôtes compatibles IPv6
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Prérequis
La procédure décrite dans ce didacticiel nécessite la configuration minimale suivante du serveur :
- Les trois nœuds ont Debian 8, je recommanderai de suivre ce guide https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
Étape 1. Installer le cluster Percona Xtradb
Sur tous les nœuds, exécutez les commandes suivantes en tant que root :
wget https://repo.percona.com/apt/percona-release_0.1-4.$(lsb_release -sc)_all.deb
dpkg -i percona-release_0.1-4.$( lsb_release -sc)_all.deb
apt-get update
apt-get -y install percona-xtradb-cluster-57
Évidemment, entrez le mot de passe mysql que vous souhaitez choisir.
Une fois les packages installés, mysqld démarrera automatiquement. Arrêtez mysqld sur les trois nœuds en utilisant /etc/init.d/mysql stop .
Étape 2. Configuration du premier nœud
Les nœuds individuels doivent être configurés pour pouvoir démarrer le cluster. Pour plus d'informations sur l'amorçage du cluster, consultez Amorcer le cluster .
-
Assurez-vous d'ajouter ces lignes au fichier de configuration /etc/mysql/my.cnf pour le premier noeud (mysql1.local.vm) à la fin de la section [mysqld] :
[mysqld]
...# Chemin d'accès à la bibliothèque Galera
wsrep_provider=/usr/lib/libgalera_smm.so
# L'URL de connexion au cluster contient le Adresses IP du nœud 1, du nœud 2 et du nœud #3 le format binlog doit être ROW
binlog_format=ROW
# Le moteur de stockage MyISAM n'a qu'un support expérimental
default_storage_engine=InnoDB
# Ce mode de verrouillage d'auto-incrémentation InnoDB est une exigence pour Galera
innodb_autoinc_lock_mode=2
# Adresse du nœud #1
wsrep_node_address=192.168.152.100
# Méthode SST
wsrep_sst_method=xtrabackup-v2
# Nom du cluster
wsrep_cluster_name=my_ubuntu_cluster
# Authentification pour la méthode SST
wsrep_sst_auth="sstuser:PASSW0RD"Faites attention au mot de passe que vous y avez configuré dans mon cas "PASSW0RD".
-
Démarrez le premier nœud avec la commande suivante :
[email protected] :~# /etc/init.d/mysql bootstrap-pxc
Cette commande démarrera le premier nœud et démarrera le cluster, vous verrez quelque chose comme ceci si tout va bien :
[email protected] :~# /etc/init.d/mysql bootstrap-pxc
[ ok ] Amorçage du serveur de base de données Percona XtraDB Cluster :mysqld ..
[email protected] :~# -
Une fois le premier nœud démarré, connectez-vous à mysql avec la commande classique mysql -p, puis l'état du cluster peut être vérifié en exécutant la requête show status like 'wsrep%' ; comme dans l'exemple ci-dessous :
mysql> afficher l'état comme 'wsrep%' ;+----------------------------+---- ----------------------------------+| nom_variable | Valeur |+----------------------------+------------------ --------------------+| wsrep_local_state_uuid | 0251a27c-8a19-11e6-905b-f3f13b0ddc5b |...| wsrep_local_state | 4 || wsrep_local_state_comment | Synchronisé |...| wsrep_cluster_size | 1 || wsrep_cluster_status | Primaire || wsrep_connecté | MARCHE |...| wsrep_ready | MARCHE |+----------------------------+------------------ --------------------+59 lignes dans l'ensemble (0.00 sec)
Cette sortie montre que le cluster a été démarré avec succès.
Pour effectuer un transfert d'instantané d'état en utilisant XtraBackup , configurez un nouvel utilisateur avec les privilèges appropriés :
mysql> CREATE USER 'sstuser'@'localhost' IDENTIFIED BY 'PASSW0RD';mysql> GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sstuser'@'localhost';mysql> FLUSH PRIVILEGES;
Remarque
Le compte root MySQL peut également être utilisé pour effectuer SST, mais il est plus sûr d'utiliser un autre utilisateur (non root) pour cela.
Étape 3. Configuration du deuxième nœud
-
Ajoutez les lignes suivantes au fichier de configuration /etc/mysql/my.cnf sur le deuxième nœud (mysql2.local.vm), afin qu'il contienne les données suivantes :
[mysqld]
...# Chemin d'accès à la bibliothèque Galera
wsrep_provider=/usr/lib/libgalera_smm.so
# L'URL de connexion au cluster contient le Adresses IP du nœud 1, du nœud 2 et du nœud #3 le format binlog doit être ROW
binlog_format=ROW
# Le moteur de stockage MyISAM n'a qu'un support expérimental
default_storage_engine=InnoDB
# Ce mode de verrouillage d'auto-incrémentation InnoDB est une exigence pour Galera
innodb_autoinc_lock_mode=2
# Adresse du nœud #2
wsrep_node_address=192.168.152.110
# Méthode SST
wsrep_sst_method=xtrabackup-v2
# Nom du cluster
wsrep_cluster_name=my_ubuntu_cluster
# Authentification pour la méthode SST
wsrep_sst_auth="sstuser:PASSW0RD" -
Démarrez le deuxième noeud avec la commande suivante (attention cette fois comme vous pouvez le voir n'est pas en mode boostrap !!):
[email protected] :~# /etc/init.d/mysql start
-
Une fois le serveur démarré, il doit recevoir SST automatiquement. L'état du cluster peut maintenant être vérifié sur les deux nœuds. Voici un exemple de l'état du deuxième nœud (mysql2.local.vm) :
mysql> afficher l'état comme 'wsrep%' ;+----------------------------+---- ----------------------------------+| nom_variable | Valeur |+----------------------------+------------------ --------------------+| wsrep_local_state_uuid | 0251a27c-8a19-11e6-905b-f3f13b0ddc5b |...| wsrep_local_state | 4 || wsrep_local_state_comment | Synchronisé |...| wsrep_cluster_size | 2 || wsrep_cluster_status | Primaire || wsrep_connecté | MARCHE |...| wsrep_ready | MARCHE |+----------------------------+------------------ --------------------+40 lignes dans l'ensemble (0,01 s)
Cette sortie montre que le nouveau nœud a été ajouté avec succès au cluster. Notez la variable wsrep_cluster_size qui est devenue 2, au lieu de l'une des premières requêtes que nous avons faites.
Étape 4. Configuration du troisième nœud
-
Ajoutez les lignes suivantes au fichier de configuration /etc/mysql/my.cnf sur le deuxième nœud (mysql3.local.vm), il contient donc la configuration suivante :
[mysqld]
...# Chemin d'accès à la bibliothèque Galera
wsrep_provider=/usr/lib/libgalera_smm.so
# L'URL de connexion au cluster contient le Adresses IP du nœud 1, du nœud 2 et du nœud #3 le format binlog doit être ROW
binlog_format=ROW
# Le moteur de stockage MyISAM n'a qu'un support expérimental
default_storage_engine=InnoDB
# Ce mode de verrouillage d'auto-incrémentation InnoDB est une exigence pour Galera
innodb_autoinc_lock_mode=2
# Adresse du nœud #2
wsrep_node_address=192.168.152.120
# Méthode SST
wsrep_sst_method=xtrabackup-v2
# Nom du cluster
wsrep_cluster_name=my_ubuntu_cluster
# Authentification pour la méthode SST
wsrep_sst_auth="sstuser:PASSW0RD" -
Démarrez le troisième nœud avec la commande suivante :
[email protected] :~# /etc/init.d/mysql start
-
Une fois le serveur démarré, il devrait recevoir SST automatiquement. L'état du cluster peut être vérifié sur tous les nœuds. Voici un exemple de statut du troisième nœud (mysql3.local.vm) :
mysql> afficher le statut comme 'wsrep%' ;+----------------------------+------- -------------------------------+| nom_variable | Valeur |+----------------------------+------------------ --------------------+| wsrep_local_state_uuid | 0251a27c-8a19-11e6-905b-f3f13b0ddc5b |...| wsrep_local_state | 4 || wsrep_local_state_comment | Synchronisé |...| wsrep_cluster_size | 3 || wsrep_cluster_status | Primaire || wsrep_connecté | MARCHE |...| wsrep_ready | MARCHE |+----------------------------+------------------ --------------------+40 lignes dans l'ensemble (0,01 s)
Cette sortie confirme que le troisième nœud a rejoint le cluster. Jetez à nouveau un coup d'œil à wsrep_cluster_size qui est maintenant devenu 3, au lieu de 2.
Si vous rencontrez des problèmes, jetez un œil à /var/log/syslog pour voir si tout va bien
Oct 4 12:16:13 mysql3 mysql[2767] :Démarrage du serveur de base de données MySQL (Percona XtraDB Cluster) :mysqld . . .Transfert d'état en cours, mise en veille supérieure :mysqld . ..
4 oct. 12:16:13 mysql3 systemd[1] :LSB démarré :démarrez et arrêtez le démon mysql (Percona XtraDB Cluster).
4 oct. 12:17:01 mysql3 CRON[3731] :(racine) CMD ( cd / &&run-parts --report /etc/cron.hourly)
Dans cet exemple, tout s'est bien passé et vous pouvez voir le transfert d'état en cours, ce qui signifie que les données seront transférées vers le nœud.
Tester la réplication
Pour tester la réplication, créons une nouvelle base de données sur le deuxième nœud, créons une table pour cette base de données sur le troisième nœud et ajoutons quelques enregistrements à la table sur le premier nœud.
-
Créez une nouvelle base de données sur le deuxième nœud :
mysql@mysql2> CREATE DATABASE percona;Requête OK, 1 ligne affectée (0.01 sec)
-
Créez une table sur le troisième nœud :
mysql@mysql3> USE percona;Base de données modifiéemysql@pxc3> Exemple de CREATE TABLE (node_id INT PRIMARY KEY, node_name VARCHAR(30));Requête OK, 0 lignes affectées (0.05 sec)
-
Insérer des enregistrements sur le premier nœud :
mysql@mysql1> INSERT INTO percona.example VALUES (1, 'percona1');Requête OK, 1 ligne affectée (0.02 sec)
-
Récupérez toutes les lignes de cette table sur le deuxième nœud :
mysql@mysql2> SELECT * FROM percona.example;+---------+-----------+| nœud_id | nom_noeud |+---------+-----------+| 1 | percona1 |+---------+-----------+1 ligne dans l'ensemble (0.00 sec)
Pour vous assurer que votre application peut toujours atteindre le cluster, vous pouvez ajouter un équilibreur de charge devant les trois nœuds.