La mise à niveau de votre base de données pour les clusters basés sur Galera tels que Percona XtraDB Cluster (PXC) ou MariaDB Galera Cluster peut être difficile, en particulier pour un environnement basé sur la production. Vous ne pouvez pas vous permettre de perdre l'état de votre haute disponibilité et de la mettre en danger.
Une procédure de mise à niveau doit être bien documentée et, idéalement, une documentation, des tests rigoureux et une analyse comparative doivent être effectués avant les mises à niveau. Plus important encore, la sécurité et les améliorations doivent également être identifiées en fonction du journal des modifications de la mise à niveau de la version de sa base de données.
Avec toutes ces préoccupations, l'automatisation permet d'obtenir un processus de mise à niveau plus efficace, d'éviter les erreurs humaines et d'améliorer le RTO.
Comment gérer le processus de mise à niveau du cluster PXC/MariaDB Galera
La mise à niveau de votre cluster Galera PXC/MariaDB nécessite une documentation et un flux de processus appropriés qui répertorient les choses à faire et ce qu'il faut faire au cas où les choses tourneraient mal. Cela signifie qu'un plan de continuité des activités qui couvrira également votre plan de reprise après sinistre doit être établi. Vous ne pouvez pas vous permettre de perdre votre entreprise en cas de problème.
La prise habituelle est de commencer par l'environnement de test. L'environnement de test doit avoir exactement les mêmes paramètres et la même configuration que votre environnement de production. Vous ne pouvez pas procéder directement à la mise à niveau de l'environnement de production car vous n'êtes pas sûr de l'effet et de l'impact qu'il aura si les choses ne sont pas conformes au plan.
Travailler avec un environnement de production est très sensible, donc dans la plupart des cas, une fenêtre de temps d'arrêt et de maintenance est toujours là pour éviter un impact drastique.
Il existe deux types de mise à niveau pour PCX ou MariaDB Galera Cluster dont vous devez être conscient. Il s'agit de la mise à niveau de la version majeure et de la mise à niveau de la version mineure ou souvent appelée mise à niveau sur place. Une mise à niveau sur place vous permet de mettre à niveau votre version de base de données vers sa version mineure la plus récente en utilisant les mêmes données binaires de votre base de données. Il n'y aura aucun changement physique sur les données elles-mêmes, mais uniquement sur sa base de données binaire ou sur les progiciels sous-jacents.
Mettre à niveau PCX ou MariaDB Galera Cluster vers une version majeure
La mise à niveau vers une version majeure peut être difficile, en particulier pour un environnement de production. Cela implique un type complexe de configuration de base de données et des fonctionnalités intégrées spéciales de PXC ou MariaDB Galera Cluster. Les données spatio-temporelles, horodatées, les données machine ou toutes données à multiples facettes sont très conservatrices et sensibles aux mises à niveau. Vous ne pouvez pas appliquer une mise à niveau sur place pour ce processus car de nombreuses modifications majeures auraient été apportées. À moins que vous n'ayez de très petites données ou des données composées d'idempotents ou des données qui peuvent être générées facilement, vous pouvez le faire en toute sécurité tant que vous savez que l'impact n'affectera pas vos données.
Si votre volume de données est important, il est préférable d'automatiser le processus de mise à niveau. Cependant, automatiser toute la séquence du processus de mise à niveau n'est peut-être pas une solution idéale, car des problèmes inattendus peuvent survenir pendant la phase de mise à niveau majeure. Il est préférable d'automatiser les étapes et les processus répétitifs avec des résultats connus dans une mise à niveau majeure. À tout moment, une ressource est nécessaire pour évaluer si le processus d'automatisation est sûr afin d'éviter tout arrêt du processus de mise à niveau. Les tests automatisés après la mise à niveau sont tout aussi importants et doivent être inclus dans le processus de post-mise à niveau.
Mettre à niveau PCX ou MariaDB Galera Cluster vers une version mineure
Une mise à niveau de version mineure appelée mise à niveau sur place est généralement une approche plus sûre pour effectuer un processus de mise à niveau. En effet, les changements les plus courants pour cette version sont des correctifs ou des améliorations de sécurité et d'exploitation, des bogues (généralement graves) ou des problèmes de compatibilité qui nécessitent des correctifs, en particulier si le matériel ou le système d'exploitation actuel a été appliqué à des modifications pouvant également empêcher la base de données de fonctionner. fonctionner correctement. Bien que l'impact puisse généralement être récupéré avec un effet minimal, il est toujours indispensable que vous regardiez et lisiez le journal des modifications qui a été poussé vers la mise à niveau de la version mineure spécifique.
Le déploiement de la tâche pour effectuer le processus de mise à niveau est un exemple idéal d'automatisation. Le flux habituel est très répétitif et ne cause généralement aucun dommage à votre cluster PXC ou MariaDB Galera existant. Ce qui compte le plus, c'est qu'après la mise à niveau, les tests automatisés se poursuivent pour déterminer que l'installation, la configuration, l'efficacité et les fonctionnalités ne sont pas interrompues.
Évitez les fiascos ! Soyez prêt, faites-le automatiser !
Un de nos clients nous a contacté pour nous demander de l'aide car, après la mise à niveau mineure de la base de données, une fonctionnalité qu'il utilise dans la base de données ne fonctionne pas correctement. Ils ont demandé des étapes et des processus sur la façon de rétrograder et sur la sécurité. Leurs clients se plaignaient que leur application ne fonctionnait absolument pas, généralisant qu'elle n'était pas utile.
Même pour un si petit pépin, un client énervé pourrait donner une mauvaise remarque à votre produit. La leçon tirée de ce scénario est que l'échec des tests après une mise à niveau conduit à supposer que toutes les fonctions d'une base de données fonctionnent comme prévu.
Supposons que vous prévoyiez d'automatiser le processus de mise à niveau, puis notez que le type de processus d'automatisation varie en fonction du type de mises à niveau que vous devez effectuer. Comme mentionné précédemment, une mise à niveau majeure par rapport à une mise à niveau mineure a différentes approches distinctes. Par conséquent, la configuration de votre automate peut ne pas s'appliquer aux deux mises à niveau du logiciel de base de données.
Automatisation après le processus de mise à niveau
À ce stade, on s'attend à ce que votre processus de mise à niveau soit effectué, idéalement, par le biais de l'automatisation. Maintenant que votre base de données est prête à recevoir des connexions client, elle doit suivre une phase de test rigoureuse.
Exécuter mysql_upgrade
Il est très important et extrêmement recommandé d'exécuter mysql_upgrade une fois le processus de mise à jour terminé. mysql_upgrade recherche les incompatibilités avec le serveur MySQL mis à jour en procédant comme suit :
-
Il met à niveau les tables système dans le schéma mysql afin que vous puissiez profiter de nouveaux privilèges ou capacités qui pourraient ont été ajoutés.
-
Il met à niveau le schéma de performance et le schéma sys.
-
Il examine les schémas utilisateur.
Mysql_upgrade détermine si une table a des problèmes tels que des incompatibilités dues à des changements dans la version la plus récente après la mise à niveau et tente de le résoudre en réparant la table. Sinon, s'il échoue, votre test d'automatisation devra échouer et ne doit pas passer à autre chose. Il doit d'abord faire l'objet d'une enquête et effectuer une réparation manuelle.
Vérifier les journaux d'erreurs
Une fois mysql_upgrade terminé, vous devez vérifier et vérifier les erreurs qui se sont produites. Vous pouvez mettre cela dans un script et vérifier les étiquettes "erreur" ou "avertissement" dans les journaux d'erreurs. Il est très important de déterminer s'il y en a. Votre test automatisé doit avoir la capacité d'attraper les pièges d'erreur ou il peut attendre qu'une entrée utilisateur continue si l'erreur est très minime ou attendue, sinon arrêtez le processus de mise à niveau.
Effectuer un test unitaire
Un environnement de base de données TDD (Test Driven Development) est une approche de développement logiciel où il y a une série de cas de test à valider et à déterminer si la validation est vraie (réussite) ou fausse (échec). Quelque chose comme ce que nous avons dans la capture d'écran ci-dessous :
Image reproduite avec l'aimable autorisation de guru99.com
Il s'agit d'un type de test unitaire qui permet d'éviter les bogues indésirables ou les erreurs logiques dans votre application et dans votre base de données. N'oubliez pas que si des données invalides sont stockées dans la base de données, cela nuirait à toutes les analyses et transactions commerciales, en particulier si cela implique des calculs financiers complexes ou des équations mathématiques.
Si vous demandez, est-il vraiment nécessaire d'effectuer un test unitaire après la mise à niveau ? Bien sûr, ça l'est ! Vous n'avez pas nécessairement besoin de l'exécuter dans l'environnement de production. Pendant les phases de test, c'est-à-dire la mise à niveau d'abord de vos QA, de votre environnement de développement/de staging, il doit être appliqué dans ce domaine. Les données doivent être une copie exacte au moins ou presque identique à son environnement de production. Votre objectif ici est d'éviter les résultats indésirables et les résultats logiques définitivement erronés. Vous devez bien sûr prendre soin de vos données et déterminer si les résultats passent le test de validation.
Si vous avez l'intention d'exécuter votre production, faites-le. Cependant, ne soyez pas aussi rigide que votre phase de test appliquée dans l'environnement d'assurance qualité, de développement ou de mise en scène. C'est parce que vous devez planifier votre temps en fonction de la fenêtre de maintenance disponible et éviter les retards et les RTO plus longs.
D'après mon expérience, lors de la phase de mise à niveau, les clients sélectionnent une approche plus rapide qui sera importante pour déterminer si une telle fonctionnalité fournit le bon résultat. De plus, vous pouvez disposer d'un script pour automatiser le test d'un ensemble de fonctions logiques métier ou de procédures stockées puisqu'il permet de mettre en cache les requêtes et de chauffer votre base de données.
Lors de la préparation du test unitaire pour votre base de données, évitez de réinventer la roue. Au lieu de cela, jetez un coup d'œil aux outils disponibles que vous pouvez choisir s'ils conviennent à vos exigences et à vos besoins. Découvrez Selenium, ou allez voir ce blog.
Vérifier l'identité des requêtes
L'outil le plus courant que vous pouvez utiliser est le pt-upgrade de Percona. Il vérifie que les résultats des requêtes sont identiques sur différents serveurs. Il exécute des requêtes basées sur les journaux donnés et la connexion fournie (ou appelée DSN), puis compare les résultats et signale toute différence significative. Il offre plus que cela comme options pour collecter ou analyser les requêtes, par exemple via tcpdump.
L'utilisation de pt-upgrade est facile. Par exemple, vous pouvez exécuter la commande suivante :
## Comparing via slow log for the given hosts
pt-upgrade h=host1 h=host2 slow.log
## or use fingerprints, useful for debugging purposes
pt-upgrade --fingerprints --run-time=1h mysqld-slow.log h=127.0.0.1,P=5091 h=127.0.0.1,P=5517
## or with tcpdump,
tcpdump -i eth0 port 3306 -s 65535 -x -n -q -tttt \
| pt-query-digest --type tcpdump --no-report --print \
| pt-upgrade h=host1 h=host2C'est une bonne pratique qu'une fois qu'une mise à niveau, en particulier une mise à niveau de version majeure, a été effectuée, pt-upgrade est utilisé pour continuer et effectuer une analyse de requête identifiant les différences en fonction des résultats. C'est une bonne pratique de le faire pendant la phase de test tout en le faisant sur votre QA ou votre environnement de test et de développement afin que vous puissiez décider s'il est plus sûr de continuer. Vous pouvez l'ajouter à votre outil d'automatisation et l'exécuter comme un playbook une fois qu'il est prêt à accomplir sa tâche.
Comment automatiser le processus de test ?
Dans nos blogs précédents, nous avons présenté différentes manières d'automatiser vos bases de données. Les outils les plus courants qui sont en vogue sont ces outils logiciels de déploiement IaC (Infrastructure as Code). Vous pouvez utiliser Puppet, Chef, SaltStack ou Ansible pour faire le travail.
Ma préférence a toujours été Ansible pour effectuer mes tests automatisés, cela me permet de créer des playbooks par rôle. Bien sûr, je ne peux pas créer un automate qui fera tout car la situation et l'environnement varient. En fonction des types de mise à niveau donnés précédemment (mise à niveau majeure ou mineure), vous devez faire la distinction entre son processus. Même s'il ne s'agit que d'une mise à niveau sur place, vous devez toujours vous assurer que vos playbooks effectuent le bon travail.
ClusterControl est votre ami pour l'automatisation des bases de données !
ClusterControl est une bonne option pour effectuer des tests de base et automatisés. ClusterControl n'est pas un cadre de test; ce n'est pas un outil pour fournir des tests unitaires. Cependant, il s'agit d'un outil de gestion et de surveillance de base de données qui intègre de nombreux déploiements automatisés basés sur les déclencheurs demandés par l'utilisateur ou l'administrateur du logiciel.
ClusterControl propose des mises à niveau de version mineures, ce qui facilite la tâche des DBA lors de l'exécution des mises à niveau. Il effectue également mysql_upgrade à la volée. Vous n'avez donc pas besoin de l'exécuter manuellement. ClusterControl détecte également les nouvelles versions à mettre à niveau et vous recommande les prochaines étapes à suivre. En cas d'échec, la mise à niveau ne se poursuivra pas.
Voici un exemple de tâche de mise à niveau mineure :
Si vous regardez attentivement, mysql_upgrade s'exécute avec succès. Bien qu'il ne recommande pas et effectue une mise à niveau automatique du maître, c'est parce que ce n'est pas la bonne approche pour continuer. Dans ce cas, vous devez promouvoir le nouvel esclave, puis rétrograder le maître en tant qu'esclave pour effectuer la mise à niveau.
Conclusion
L'avantage de ClusterControl est que vous pouvez intégrer la vérification des journaux d'erreurs, effectuer un test unitaire, vérifier l'identité des requêtes en créant des conseillers. Ce n'est pas difficile à faire. Vous pouvez vous référer à notre blog précédent Utilisation de ClusterControl Advisor pour créer des vérifications pour SELinux et Meltdown/Spectre :première partie. Cela illustre comment vous pouvez en tirer parti et déclencher la prochaine tâche à effectuer une fois la mise à niveau exécutée. ClusterControl dispose d'alertes ou d'alarmes intégrées qui peuvent s'intégrer à vos systèmes d'alerte tiers préférés pour vous informer de l'état actuel de vos tests automatisés.
