MariaDB propose deux solutions différentes de haute disponibilité (HA) et de clustering. La première est la réplication maître/esclave MariaDB standard qui peut être configurée dans différentes topologies, principalement à des fins d'équilibrage de charge, de haute disponibilité et de sauvegarde. Le second est MariaDB Galera, une solution de clustering synchrone multi-maîtres. Ses principales fonctionnalités sont les suivantes :
- Multi-maître :tous les nœuds d'un cluster Galera peuvent effectuer des opérations de lecture et d'écriture, offrant une meilleure évolutivité.
- Les nœuds peuvent rejoindre un cluster automatiquement et sont supprimés en cas d'échec.
- La réplication de Galera est synchrone, ce qui signifie que les modifications sur un nœud sont garanties d'être appliquées sur les autres nœuds. En théorie, cela garantit qu'aucune donnée n'est perdue lorsqu'un nœud tombe en panne.
Ce guide vous guidera tout au long de l'installation de MariaDB et de sa configuration dans un cluster Galera. Nous utiliserons trois nœuds Debian 10 pour la démonstration, bien que n'importe quel nombre (≥3) de nœuds puisse être utilisé. La configuration de deux nœuds dans un cluster Galera est techniquement possible mais ne fournit pas de tolérance aux pannes car un nœud défaillant entraînera l'arrêt de l'autre nœud.
Exigences
- Trois instances Debian 10 ou plus.
- Accès à l'utilisateur racine ou à tout utilisateur disposant des privilèges sudo.
- Le $EDITOR la variable d'environnement doit être définie.
REMARQUE : Les clusters Galera peuvent fonctionner sur WAN ou LAN. Si vos nœuds partagent un réseau privé, utilisez des adresses IP privées, le cas échéant. Sinon, les adresses WAN doivent être utilisées.
Si vous utilisez un utilisateur sudo, ouvrez et utilisez un shell root pour la durée de cette configuration en utilisant :
sudo -s
Étape 1 :Installer MariaDB
Cette étape doit être exécutée sur tous les nœuds.
Utilisez les commandes suivantes pour installer MariaDB, la bibliothèque Galera et Rsync. Ce dernier est utilisé par Galera.
apt updateapt install -y mariadb-server mariadb-client galera-3 rsync
Assurez-vous que le service MariaDB est activé :
systemctl activer mariadb.service
Sécurisez vos instances MariaDB à l'aide du script mysql_secure_installation :
mysql_secure_installation
Répondez aux questions comme indiqué ci-dessous et assurez-vous de choisir un mot de passe fort pour l'utilisateur racine MySQL.
Entrez le mot de passe actuel pour root (entrez pour aucun) :Appuyez surDéfinir le mot de passe root ? [O/n] yNouveau mot de passe :votre_motdepasseEntrez à nouveau le nouveau mot de passe :votre_motdepasseSupprimer les utilisateurs anonymes ? [O/n] yInterdire la connexion root à distance ? [O/n] ySupprimer la base de données de test et y accéder ? [O/n] yRecharger les tables de privilèges maintenant ? [O/n] yTout est fait ! Si vous avez terminé toutes les étapes ci-dessus, votre installation de MariaDB devrait maintenant être sécurisée.
Étape 2 :Configurer MariaDB
Cette étape doit être exécutée sur tous les nœuds.
Arrêtez le service MariaDB sur tous les nœuds :
systemctl stop mariadb.service
Par défaut, le démon MariaDB écoute les connexions sur localhost uniquement. Pour que le cluster fonctionne, il doit être remplacé par une adresse accessible de l'extérieur. Pour cela, éditez le fichier d'options /etc/mysql/mariadb.conf.d/50-server.cnf :
$EDITOR /etc/mysql/mariadb.conf.d/50-server.cnf
Recherchez la ligne suivante :
bind-address =127.0.0.1
Si vous utilisez un réseau privé pour le cluster et que vous ne souhaitez pas exposer MariaDB à d'autres réseaux (c'est-à-dire WAN), spécifiez l'adresse IPv4 locale pour chaque nœud. Sinon, utilisez 0.0.0.0 qui demande à MariaDB d'écouter sur toutes les interfaces. Par exemple :
adresse de liaison =0.0.0.0
Enregistrez la modification et quittez votre éditeur de texte.
Nous allons maintenant configurer les options liées au cluster. Créez un nouveau fichier d'option :
$EDITOR /etc/mysql/mariadb.conf.d/99-cluster.cnf
Entrez la configuration sensée suivante dans le fichier, en remplaçant les adresses IP. Il doit être identique sur tous les nœuds.
[galera]
wsrep_on =on wsrep_provider =/lib/galera/libgalera_smm.so wsrep_cluster_address =gcomm://192.0.2.1,192.0.2.2,192.0.2.3 wsrep_cluster_name =galera_cluster_0 default_storage_engine =InnoDB innodb_autoinc_lock_mode =double innodb_mode =2 =1 binlog_format =ROW
- wsrep_on =on active la réplication du jeu d'écriture, la fonctionnalité sous-jacente utilisée par Galera.
- wsrep_provider spécifie le chemin d'accès à la bibliothèque galera. Il est fourni par le paquet galera-3 dans /lib/galera/libgalera_smm.so sur Debian 10.
- wsrep_cluster_address doit contenir au moins une adresse d'un autre membre du cluster. Il est recommandé de répertorier tous les membres du cluster. Aucune commande particulière n'est nécessaire.
- wsrep_cluster_name doit être unique pour le cluster et doit être identique sur tous les nœuds du même cluster galera.
- Les options restantes sont nécessaires au bon fonctionnement de Galera et ne doivent pas être modifiées.
Étape 3 :Amorcer le cluster
Assurez-vous que MariaDB est arrêté/inactif sur tous les nœuds avant de continuer :
statut systemctl mariadb.service
Pour démarrer le cluster, un nœud doit d'abord le créer. Sur Debian 10, cela peut être fait avec le script galera_new_cluster. Le script ne doit être exécuté que sur un nœud et une seule fois pour initialiser le cluster.
galera_new_cluster
Cela démarrera MariaDB sur le nœud actuel. Assurez-vous qu'il fonctionne avec :
statut systemctl mariadb.service
Ensuite, démarrez MariaDB sur les autres nœuds avec :
systemctl démarrer mariadb.service
Le cluster devrait maintenant être opérationnel.
Étape 4 :Tester
Pour vous assurer que le cluster fonctionne comme prévu, choisissez n'importe quel nœud et connectez-vous à MariaDB :
mysql -u root -p
Émettez l'instruction suivante pour créer une base de données :
> CRÉER BASE DE DONNÉES test0 ;> \q
Recherchez ensuite cette nouvelle base de données sur tous les autres nœuds :
mysql -u root -p -e "AFFICHER LES BASES DE DONNÉES ;"
La commande ci-dessus doit renvoyer une liste contenant test0 :
+--------------------+| Base de données |+--------------------+| information_schema || mysql || performance_schema || test0 |+--------------------+
Vous souhaiterez peut-être effectuer des tests plus approfondis en écrivant dans le cluster à partir de chaque nœud. Une fois que vous êtes satisfait des tests, nettoyez toutes les bases de données inutiles du cluster. N'importe quel nœud peut être utilisé.
mysql -u root -p -e "DROP DATABASE test0;"
Étape 5 :Conseils de dépannage
Utilisez la requête suivante pour afficher des informations sur l'état actuel du nœud/cluster :
mysql -u root -p -e "SELECT * FROM information_schema.global_status WHERE variable_name IN ('WSREP_CLUSTER_STATUS','WSREP_LOCAL_STATE_COMMENT','WSREP_CLUSTER_SIZE','WSREP_EVS_REPL_LATENCY','WSREP_EVS_DELAYED','WSREP_READY');"
Un cluster sain à 3 nœuds doit renvoyer les éléments suivants :
+---------------------------+----------------+| VARIABLE_NAME | VARIABLE_VALUE |+---------------------------+----------------+| WSREP_CLUSTER_SIZE | 3 || WSREP_CLUSTER_STATUS | Primaire || WSREP_EVS_DELAYED | || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT | Synchronisé || WSREP_READY | MARCHE |+---------------------------+----------------+
- WSREP_CLUSTER_SIZE représente le nombre actuel de nœuds dans le composant de cluster.
- WSREP_CLUSTER_STATUS représente l'état du composant de cluster et non le cluster dans son ensemble.
- WSREP_EVS_DELAYED affiche une liste des nœuds retardés. Une valeur vide est attendue des clusters sains.
- WSREP_EVS_REPL_LATENCY affiche la latence de réplication au format min/avg/max/stddev/samplesize. Les valeurs sont affichées en secondes. Des latences très élevées peuvent entraîner une dégradation des performances.
- WSREP_LOCAL_STATE_COMMENT affiche l'état actuel du nœud.
- WSREP_READY indique si le nœud peut accepter des requêtes.
Lorsqu'un nœud d'un cluster à 3 nœuds perd sa connectivité, le cluster est partitionné en un composant principal composé de 2 nœuds et d'un composant non principal. Le composant principal n'est pas affecté par la panne et continue de fonctionner normalement. Du point de vue du composant non principal, la requête ci-dessus renverrait ce qui suit :
+---------------------------+------------------ -------------------------------------------------- -------------------------------------------------- ----------+| VARIABLE_NAME | VARIABLE_VALUE |+---------------------------+-------------------------------- -------------------------------------------------- -------------------------------------------------- ---------+| WSREP_CLUSTER_SIZE | 1 || WSREP_CLUSTER_STATUS | non primaire || WSREP_EVS_DELAYED | 6b7864f2-fe7d-11e9-84ab-93e58c0d2907:tcp://192.0.2.1:4567:3,a421be89-fe7d-11e9-a91e-7e62f7562e58:tcp://192.0.2.3:4567:2 || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT | Initialisé || WSREP_READY | ARRÊT |+---------------------------+---------------------------- -------------------------------------------------- -------------------------------------------------- ---------+
Notez la valeur WSREP_EVS_DELAYED, qui indique des problèmes de connectivité avec les autres nœuds.
Sur les nœuds du composant principal, la même requête renvoie :
+---------------------------+------------------ ----------------------------------------------+| VARIABLE_NAME | VARIABLE_VALUE |+---------------------------+-------------------------------- ---------------------------------------------+| WSREP_CLUSTER_SIZE | 2 || WSREP_CLUSTER_STATUS | Primaire || WSREP_EVS_DELAYED | a2217526-fe7d-11e9-8692-1f2f0cdb403d:tcp://192.0.2.2:4567:2 || WSREP_EVS_REPL_LATENCY | 0/0/0/0/0 || WSREP_LOCAL_STATE_COMMENT | Synchronisé || WSREP_READY | MARCHE |+----------------------------+-------------- ---------------------------------------------+
Pour récupérer des défaillances d'un seul nœud, aucune intervention manuelle n'est requise. Lorsque le nœud défaillant se reconnecte au cluster, il se synchronise automatiquement avec le cluster.
Plus d'informations
Pour les options de configuration avancées, reportez-vous à Galera Cluster System Variables.