Il existe plusieurs manières de déployer une base de données. Vous pouvez l'installer à la main, vous pouvez compter sur les outils d'orchestration d'infrastructure largement disponibles comme Ansible, Chef, Puppet ou Salt. Ces outils sont très populaires et il est assez facile de trouver des scripts, des recettes, des playbooks, etc., qui vous aideront à automatiser l'installation d'un cluster de bases de données. Il existe également des plates-formes d'automatisation de bases de données plus spécialisées, telles que ClusterControl, qui peuvent également être utilisées pour un déploiement automatisé. Quelle serait la meilleure façon de déployer votre cluster ? Combien de temps vous faudra-t-il réellement pour le déployer ?
Tout d'abord, clarifions ce que nous voulons faire. Supposons que nous allons déployer Percona XtraDB Cluster 5.7. Il sera composé de trois nœuds et pour cela nous utiliserons trois machines virtuelles Vagrant exécutant Ubuntu 16.04 (image bento/ubuntu-16.04). Nous allons tenter de déployer un cluster manuellement, puis en utilisant Ansible et ClusterControl. Voyons à quoi ressembleront les résultats.
Déploiement manuel
Configuration du référentiel - 1 minute, 45 secondes.
Tout d'abord, nous devons configurer les référentiels Percona sur tous les nœuds Ubuntu. Une recherche rapide sur Google, ssh dans les machines virtuelles et l'exécution des commandes requises prend 1m45s
Nous avons trouvé la page suivante avec des instructions :
https://www.percona.com/doc/percona-repo-config/percona-release.html
et nous avons exécuté les étapes décrites dans la section « DISTRIBUTIONS GNU/LINUX BASÉES SUR DEB ». Nous avons également exécuté apt update, pour actualiser le cache d'apt.
Installation des nœuds PXC - 2 minutes 45 secondes
Cette étape consiste essentiellement à exécuter :
[email protected]:~# apt install percona-xtradb-cluster-5.7Le reste dépend principalement de la vitesse de votre connexion Internet lors du téléchargement des packages. Votre entrée sera également nécessaire (vous passerez un mot de passe pour le superutilisateur) afin qu'il ne s'agisse pas d'une installation sans surveillance. Lorsque tout est terminé, vous vous retrouverez avec trois nœuds de cluster Percona XtraDB en cours d'exécution :
root 15488 0.0 0.2 4504 1788 ? S 10:12 0:00 /bin/sh /usr/bin/mysqld_safe
mysql 15847 0.3 28.3 1339576 215084 ? Sl 10:12 0:00 \_ /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --wsrep-provider=/usr/lib/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/run/mysqld/mysqld.sock --wsrep_start_position=00000000-0000-0000-0000-000000000000:-1Configuration des nœuds PXC - 3 minutes, 25 secondes
Ici commence la partie délicate. Il est vraiment difficile de quantifier l'expérience et le temps qu'il faudrait pour comprendre réellement ce qui doit être fait. Ce qui est bien, la recherche Google "comment installer le cluster percona xtrabdb" pointe vers la documentation de Percona, qui décrit à quoi devrait ressembler le processus. Cela peut encore prendre plus ou moins de temps, selon votre degré de familiarité avec le PXC et Galera en général. Dans le pire des cas, vous ne serez pas au courant des actions supplémentaires requises et vous vous connecterez à votre PXC et commencerez à travailler avec, sans vous rendre compte qu'en fait, vous avez trois nœuds, chacun formant son propre cluster.
Supposons que nous suivions la recommandation de Percona et chronométrons uniquement ces étapes à exécuter. En bref, nous avons modifié les fichiers de configuration conformément aux instructions sur le site Web de Percona, nous avons également tenté de démarrer le premier nœud :
[email protected]:~# /etc/init.d/mysql bootstrap-pxc
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
mysqld: [ERROR] Found option without preceding group in config file /etc/mysql/my.cnf at line 10!
mysqld: [ERROR] Fatal error in defaults handling. Program aborted!
* Bootstrapping Percona XtraDB Cluster database server mysqld ^CCela n'avait pas l'air correct. Malheureusement, les instructions n'étaient pas limpides. Encore une fois, si vous ne savez pas ce qui se passe, vous passerez plus de temps à essayer de comprendre ce qui s'est passé. Heureusement, stackoverflow.com est très utile (bien qu'il ne s'agisse pas de la première réponse de la liste que nous avons reçue) et vous devez réaliser qu'il vous manque l'en-tête de section [mysqld] dans votre fichier /etc/mysql/my.cnf. L'ajout de ceci sur tous les nœuds et la répétition du processus d'amorçage ont résolu le problème. Au total, nous avons passé 3 minutes et 25 secondes (sans compter la recherche de l'erreur sur Google, car nous avons immédiatement remarqué quel était le problème).
Configuration pour SST, intégration d'autres nœuds dans le cluster :de 8 minutes à l'infini
Les instructions sur le site Web de Percona sont assez claires. Une fois que vous avez un nœud opérationnel, démarrez simplement les nœuds restants et tout ira bien. Nous avons essayé cela et nous n'avons pas pu voir plus de nœuds rejoindre le cluster. C'est là qu'il est pratiquement impossible de dire combien de temps il faudra pour diagnostiquer le problème. Cela nous a pris 6-7 minutes mais pour pouvoir le faire rapidement il faut :
- Familiarisez-vous avec la structure de la configuration PXC :
[email protected]:~# tree /etc/mysql/ /etc/mysql/ ├── conf.d │ ├── mysql.cnf │ └── mysqldump.cnf ├── my.cnf -> /etc/alternatives/my.cnf ├── my.cnf.fallback ├── my.cnf.old ├── percona-xtradb-cluster.cnf └── percona-xtradb-cluster.conf.d ├── client.cnf ├── mysqld.cnf ├── mysqld_safe.cnf └── wsrep.cnf - Savoir comment les directives !include et !includedir fonctionnent dans les fichiers de configuration MySQL
- Savoir comment MySQL gère les mêmes variables incluses dans plusieurs fichiers
- Savoir ce qu'il faut rechercher et être conscient des configurations qui entraîneraient l'amorçage du nœud pour former un cluster par lui-même
Le problème était lié au fait que les instructions ne mentionnaient aucun fichier sauf pour /etc/mysql/my.cnf où, en fait, nous aurions dû modifier /etc/mysql/percona-xtradb-cluster.conf.d/wsrep .cnf. Ce fichier contenait une variable vide :
wsrep_cluster_address=gcomm://et une telle configuration force le nœud à s'amorcer car il n'a pas d'informations sur les autres nœuds auxquels se joindre. Nous avons défini cette variable dans /etc/mysql/my.cnf mais plus tard, le fichier wsrep.cnf a été inclus, écrasant notre configuration.
Ce problème peut être un obstacle sérieux pour les personnes qui ne sont pas vraiment familiarisées avec le fonctionnement de MySQL et de Galera, entraînant même des heures, voire plus, de débogage.
Temps total d'installation - 16 minutes (si vous êtes un administrateur de base de données MySQL comme moi)
Nous avons réussi à installer Percona XtraDB Cluster en 16 minutes. Vous devez garder à l'esprit deux choses - nous n'avons pas réglé la configuration. C'est quelque chose qui demandera plus de temps et de connaissances. Le nœud PXC est livré avec une configuration simple, principalement liée à la journalisation binaire et à la réplication du jeu d'écriture Galera. Il n'y a pas de réglage InnoDB. Si vous n'êtes pas familier avec les composants internes de MySQL, cela représente des heures, voire des jours, de lecture et de familiarisation avec les mécanismes internes. Une autre chose importante est qu'il s'agit d'un processus que vous devrez réappliquer pour chaque cluster que vous déployez. Enfin, nous avons réussi à identifier le problème et à le résoudre très rapidement grâce à notre expérience avec Percona XtraDB Cluster et MySQL en général. L'utilisateur occasionnel passera probablement beaucoup plus de temps à essayer de comprendre ce qui se passe et pourquoi.
Livret Ansible
Passons maintenant à l'automatisation avec Ansible. Essayons de trouver et d'utiliser un playbook ansible, que nous pourrions réutiliser pour tous les déploiements ultérieurs. Voyons combien de temps cela prendra pour le faire.
Configuration de la connectivité SSH - 1 minute
Ansible nécessite une connectivité SSH sur tous les nœuds pour les connecter et les configurer. Nous avons généré une clé SSH et l'avons distribuée manuellement sur les nœuds.
Trouver un playbook Ansible - 2 minutes 15 secondes
Le principal problème ici est qu'il y a tellement de playbooks disponibles qu'il est impossible de décider ce qui est le mieux. En tant que tel, nous avons décidé d'aller avec les 3 meilleurs résultats de Google et d'essayer d'en choisir un. Nous avons opté pour https://github.com/cdelgehier/ansible-role-XtraDB-Cluster car il semble être plus configurable que les autres.
Clonage du référentiel et installation d'Ansible - 30 secondes
C'est rapide, tout ce dont nous avions besoin était de
apt install ansible git
git clone https://github.com/cdelgehier/ansible-role-XtraDB-Cluster.gitPréparation du fichier d'inventaire - 1 minute 10 secondes
Cette étape était également très simple, nous avons créé un fichier d'inventaire en utilisant l'exemple de la documentation. Nous venons de remplacer les adresses IP des nœuds par ce que nous avons configuré dans notre environnement.
Préparer un Playbook - 1 minute 45 secondes
Nous avons décidé d'utiliser l'exemple le plus complet de la documentation, qui comprend également un peu de réglage de la configuration. Nous avons préparé une structure correcte pour Ansible (il n'y avait pas de telles informations dans la documentation) :
/root/pxcansible/
├── inventory
├── pxcplay.yml
└── roles
└── ansible-role-XtraDB-ClusterEnsuite, nous l'avons exécuté, mais nous avons immédiatement obtenu une erreur :
[email protected]:~/pxcansible# ansible-playbook pxcplay.yml
[WARNING]: provided hosts list is empty, only localhost is available
ERROR! no action detected in task
The error appears to have been in '/root/pxcansible/roles/ansible-role-XtraDB-Cluster/tasks/main.yml': line 28, column 3, but may
be elsewhere in the file depending on the exact syntax problem.
The offending line appears to be:
- name: "Include {{ ansible_distribution }} tasks"
^ here
We could be wrong, but this one looks like it might be an issue with
missing quotes. Always quote template expression brackets when they
start a value. For instance:
with_items:
- {{ foo }}
Should be written as:
with_items:
- "{{ foo }}"Cela a pris 1 minute et 45 secondes.
Résoudre le problème de syntaxe du Playbook – 3 minutes 25 secondes
L'erreur était trompeuse, mais la règle générale est d'essayer une version plus récente d'Ansible, ce que nous avons fait. Nous avons cherché sur Google et trouvé de bonnes instructions sur le site Web d'Ansible. La prochaine tentative d'exécution du playbook a également échoué :
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node2]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node3]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}
fatal: [node1]: FAILED! => {"changed": false, "msg": "The PyMySQL (Python 2.7 and Python 3.X) or MySQL-python (Python 2.X) module is required."}La configuration de la nouvelle version d'Ansible et l'exécution du playbook jusqu'à cette erreur ont pris 3 minutes et 25 secondes.
Réparer le module Python manquant - 3 minutes 20 secondes
Apparemment, le rôle que nous avons utilisé ne tenait pas compte de ses prérequis et il manquait un module Python pour se connecter et sécuriser le cluster Galera. Nous avons d'abord essayé d'installer MySQL-python via pip mais il est devenu évident que cela prendrait plus de temps car cela nécessitait mysql_config :
[email protected]:~# pip install MySQL-python
Collecting MySQL-python
Downloading https://files.pythonhosted.org/packages/a5/e9/51b544da85a36a68debe7a7091f068d802fc515a3a202652828c73453cad/MySQL-python-1.2.5.zip (108kB)
100% |████████████████████████████████| 112kB 278kB/s
Complete output from command python setup.py egg_info:
sh: 1: mysql_config: not found
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/tmp/pip-build-zzwUtq/MySQL-python/setup.py", line 17, in <module>
metadata, options = get_config()
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 43, in get_config
libs = mysql_config("libs_r")
File "/tmp/pip-build-zzwUtq/MySQL-python/setup_posix.py", line 25, in mysql_config
raise EnvironmentError("%s not found" % (mysql_config.path,))
EnvironmentError: mysql_config not found
----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-zzwUtq/MySQL-python/Cela est fourni par les bibliothèques de développement MySQL, nous devions donc les installer manuellement, ce qui était pratiquement inutile. Nous avons décidé d'utiliser PyMySQL, qui ne nécessitait pas l'installation d'autres packages. Cela nous a amené à un autre problème :
TASK [ansible-role-XtraDB-Cluster : Delete anonymous connections] *****************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1698, u\"Access denied for user 'root'@'localhost'\")"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryJusqu'à présent, nous avons passé 3 minutes et 20 secondes.
Correction de l'erreur "Accès refusé" - 18 minutes 55 secondes
Conformément à l'erreur, nous nous sommes assurés que la configuration MySQL était correctement préparée et qu'elle incluait l'utilisateur et le mot de passe corrects pour se connecter à la base de données. Cela, malheureusement, n'a pas fonctionné comme prévu. Nous avons approfondi nos recherches et constaté que le rôle ne créait pas correctement l'utilisateur root, même s'il marquait l'étape comme terminée. Nous avons fait une courte enquête mais avons décidé de faire le correctif manuel au lieu d'essayer de déboguer le playbook, ce qui prendrait beaucoup plus de temps que les étapes que nous avons faites. Nous venons de créer manuellement les utilisateurs [email protected] et [email protected] avec des mots de passe corrects. Cela nous a permis de passer cette étape et sur une autre erreur :
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the master node] ************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node1]
skipping: [node2]
skipping: [node3]
TASK [ansible-role-XtraDB-Cluster : Start the slave nodes] ************************************************************************************************************************************************************************************************************************
fatal: [node3]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node2]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
fatal: [node1]: FAILED! => {"changed": false, "msg": "Unable to start service mysql: Job for mysql.service failed because the control process exited with error code. See \"systemctl status mysql.service\" and \"journalctl -xe\" for details.\n"}
to retry, use: --limit @/root/pxcansible/pxcplay.retryPour cette section, nous avons passé 18 minutes et 55 secondes.
Résoudre le problème "Démarrer les nœuds esclaves" (partie 1) - 7 minutes 40 secondes
Nous avons essayé plusieurs choses pour résoudre ce problème. Nous avons essayé de spécifier le nœud en utilisant son nom, nous avons essayé de changer les noms de groupe, rien n'a résolu le problème. Nous avons décidé de nettoyer l'environnement à l'aide du script fourni dans la documentation et de repartir de zéro. Cela ne l'a pas nettoyé mais a juste aggravé les choses. Après 7 minutes et 40 secondes, nous avons décidé d'effacer les machines virtuelles, de recréer l'environnement et de repartir de zéro en espérant que lorsque nous ajouterons les dépendances Python, cela résoudra notre problème.
Résoudre le problème "Démarrer les nœuds esclaves" (partie 2) - 13 minutes 15 secondes
Malheureusement, la configuration des prérequis Python n'a pas aidé du tout. Nous avons décidé de terminer le processus manuellement, en amorçant le premier nœud, puis en configurant l'utilisateur SST et en démarrant les esclaves restants. Cela a terminé la configuration "automatisée" et il nous a fallu 13 minutes et 15 secondes pour déboguer, puis finalement accepter que cela ne fonctionnera pas comme prévu par le concepteur du playbook.
Débogage supplémentaire - 10 minutes 45 secondes
Nous ne nous sommes pas arrêtés là et avons décidé d'essayer encore une chose. Au lieu de s'appuyer sur des variables Ansible, nous mettons simplement l'adresse IP de l'un des nœuds en tant que nœud maître. Cela a résolu cette partie du problème et nous nous sommes retrouvés avec :
TASK [ansible-role-XtraDB-Cluster : Create SST user] ******************************************************************************************************************************************************************************************************************************
skipping: [node2]
skipping: [node3]
fatal: [node1]: FAILED! => {"changed": false, "msg": "unable to connect to database, check login_user and login_password are correct or /root/.my.cnf has the credentials. Exception message: (1045, u\"Access denied for user 'root'@'::1' (using password: YES)\")"}C'était la fin de nos tentatives - nous avons essayé d'ajouter cet utilisateur mais cela n'a pas fonctionné correctement via le playbook ansible alors que nous pouvions utiliser l'adresse IPv6 localhost pour nous connecter lors de l'utilisation du client MySQL.
Temps d'installation total - Inconnu (Échec de l'installation automatisée)
Au total, nous avons passé 64 minutes et nous n'avons toujours pas réussi à faire démarrer les choses automatiquement. Les problèmes restants sont la création d'un mot de passe root qui ne semble pas fonctionner, puis le démarrage du cluster Galera (problème utilisateur SST). Il est difficile de dire combien de temps il faudra pour le déboguer davantage. C'est certainement possible - c'est juste difficile à quantifier car cela dépend vraiment de l'expérience avec Ansible et MySQL. Ce n'est certainement pas quelque chose que n'importe qui peut simplement télécharger, configurer et exécuter. Eh bien, peut-être qu'un autre playbook aurait fonctionné différemment ? C'est possible, mais cela peut aussi entraîner des problèmes différents. Ok, il y a donc une courbe d'apprentissage à gravir et un débogage à faire, mais ensuite, lorsque vous serez prêt, vous n'aurez plus qu'à exécuter un script. Eh bien, c'est un peu vrai. Tant que les modifications introduites par le responsable ne cassent pas quelque chose dont vous dépendez ou que la nouvelle version d'Ansible casse le playbook ou que le responsable oublie simplement le projet et arrête de le développer (pour le rôle que nous avons utilisé, il y a une demande d'extraction assez utile en attente déjà depuis près d'un an, ce qui pourrait peut-être résoudre le problème de dépendance Python - il n'a pas été fusionné). À moins que vous n'acceptiez que vous deviez maintenir ce code, vous ne pouvez pas vraiment compter sur sa précision à 100 % et son fonctionnement dans votre environnement, d'autant plus que le développeur d'origine n'a aucune incitation à maintenir le code à jour. Et qu'en est-il des autres versions ? Vous ne pouvez pas utiliser ce playbook particulier pour installer PXC 5.6 ou toute version de MariaDB. Bien sûr, il existe d'autres playbooks que vous pouvez trouver. Fonctionneront-ils mieux ou passerez-vous encore des heures à essayer de les faire fonctionner ?
ClusterControlConsole unique pour l'ensemble de votre infrastructure de base de donnéesDécouvrez les autres nouveautés de ClusterControlInstallez ClusterControl GRATUITEMENTClusterControl
Enfin, voyons comment ClusterControl peut être utilisé pour déployer Percona XtraDB Cluster.
Configuration de la connectivité SSH - 1 minute
ClusterControl nécessite une connectivité SSH sur tous les nœuds pour les connecter et les configurer. Nous avons généré une clé SSH et l'avons distribuée manuellement sur les nœuds.
Configuration de ClusterControl - 3 minutes 15 secondes
La recherche rapide "ClusterControl install" nous a dirigé vers la page de documentation ClusterControl pertinente. Nous recherchions un "moyen plus simple d'installer ClusterControl", nous avons donc suivi le lien et trouvé les instructions suivantes.
Le téléchargement et l'exécution du script ont pris 3 minutes et 15 secondes, nous avons dû prendre certaines mesures pendant l'installation afin qu'il ne s'agisse pas d'une installation sans surveillance.
Connexion à l'interface utilisateur et démarrage du déploiement - 1 minute 10 secondes
Nous avons pointé notre navigateur vers l'adresse IP du nœud ClusterControl.
Nous avons transmis les informations de contact requises et l'écran de bienvenue nous a été présenté :
Prochaine étape :nous avons choisi l'option de déploiement.
Nous avons dû transmettre les détails de la connectivité SSH.
Nous avons également décidé du fournisseur, de la version, du mot de passe et des hôtes à utiliser. Tout ce processus a pris 1 minute et 10 secondes.
Déploiement du cluster Percona XtraDB - 12 minutes 5 secondes
Il ne restait plus qu'à attendre que ClusterControl termine le déploiement. Au bout de 12 minutes et 5 secondes, le cluster était prêt :
Temps d'installation total - 17 minutes 30 secondes
Ressources associées ClusterControl pour MySQL ClusterControl pour MariaDB ClusterControl pour Galera ClusterNous avons réussi à déployer ClusterControl puis le cluster PXC à l'aide de ClusterControl en 17 minutes et 30 secondes. Le déploiement PXC lui-même a pris 12 minutes et 5 secondes . A la fin nous avons un cluster de travail, déployé selon les meilleures pratiques. ClusterControl garantit également que la configuration du cluster a du sens. En bref, même si vous ne savez rien de MySQL ou de Galera Cluster, vous pouvez déployer un cluster prêt pour la production en quelques minutes. ClusterControl n'est pas seulement un outil de déploiement, c'est aussi une plate-forme de gestion - rend les choses encore plus faciles pour les personnes qui n'ont pas d'expérience avec MySQL et Galera pour identifier les problèmes de performances (via des conseillers) et effectuer des actions de gestion (augmenter et réduire le cluster, exécuter des sauvegardes, créer esclaves asynchrones de Galera). Ce qui est important, ClusterControl sera toujours maintenu et pourra être utilisé pour déployer toutes les versions de MySQL (et pas seulement MySQL/MariaDB, il prend également en charge TimeScaleDB, PostgreSQL et MongoDB). Cela a également fonctionné hors de la boîte, ce qui ne peut pas être dit des autres méthodes que nous avons testées.
Si vous souhaitez vivre la même expérience, vous pouvez télécharger gratuitement ClusterControl. Faites-nous savoir comment vous l'avez aimé.
