Dans les cinq derniers articles de la série de blogs, nous avons couvert le déploiement du clustering/réplication (MySQL / Galera, MySQL Replication, MongoDB &PostgreSQL), la gestion et la surveillance de vos bases de données et clusters existants, la surveillance des performances et de la santé, comment faire votre configuration hautement disponible via HAProxy et MaxScale et dans le dernier message, comment se préparer aux catastrophes en planifiant des sauvegardes.
Depuis ClusterControl 1.2.11, nous avons apporté des améliorations majeures au gestionnaire de configuration de la base de données. La nouvelle version permet de modifier les paramètres sur plusieurs hôtes de base de données en même temps et, si possible, de modifier leurs valeurs lors de l'exécution.
Nous avons présenté la nouvelle gestion de la configuration MySQL dans un article de blog Trucs et astuces, mais cet article de blog ira plus en profondeur et couvrira la gestion de la configuration dans ClusterControl pour MySQL, PostgreSQL et MongoDB.
Gestion de la configuration de ClusterControl
L'interface de gestion de la configuration se trouve sous Gérer> Configurations. À partir de là, vous pouvez afficher ou modifier les configurations de vos nœuds de base de données et d'autres outils gérés par ClusterControl. ClusterControl importera la dernière configuration de tous les nœuds et écrasera les copies précédentes effectuées. Actuellement, aucune donnée historique n'est conservée.
Si vous préférez modifier manuellement les fichiers de configuration directement sur les nœuds, vous pouvez réimporter la configuration modifiée en appuyant sur le bouton Importer.
Et enfin et surtout :vous pouvez créer ou modifier des modèles de configuration. Ces modèles sont utilisés chaque fois que vous déployez de nouveaux nœuds dans votre cluster. Bien sûr, toute modification apportée aux modèles ne sera pas appliquée rétroactivement aux nœuds déjà déployés qui ont été créés à l'aide de ces modèles.
Gestion de la configuration MySQL
Comme mentionné précédemment, la gestion de la configuration de MySQL a fait l'objet d'une refonte complète dans ClusterControl 1.2.11. L'interface est maintenant plus intuitive. Lors de la modification des paramètres, ClusterControl vérifie si le paramètre existe réellement. Cela garantit que votre configuration ne refusera pas le démarrage de MySQL en raison de paramètres qui n'existent pas.
Dans Gérer -> Configurations, vous trouverez un aperçu de tous les fichiers de configuration utilisés dans le cluster sélectionné, y compris les nœuds d'équilibrage de charge.
Nous utilisons une structure arborescente pour visualiser facilement les hôtes et leurs fichiers de configuration respectifs. En bas de l'arborescence, vous trouverez les modèles de configuration disponibles pour ce cluster.
Modification des paramètres
Supposons que nous devions modifier un paramètre simple comme le nombre maximum de connexions autorisées (max_connections), nous pouvons simplement modifier ce paramètre au moment de l'exécution.
Sélectionnez d'abord les hôtes auxquels appliquer cette modification.
Sélectionnez ensuite la section que vous souhaitez modifier. Dans la plupart des cas, vous voudrez changer la section MYSQLD. Si vous souhaitez modifier le jeu de caractères par défaut pour MySQL, vous devrez le modifier dans les sections MYSQLD et client.
Si nécessaire, vous pouvez également créer une nouvelle section en tapant simplement le nouveau nom de la section. Cela créera une nouvelle section dans le my.cnf.
Une fois que nous avons modifié un paramètre et défini sa nouvelle valeur en appuyant sur "Continuer", ClusterControl vérifiera si le paramètre existe pour cette version de MySQL. Ceci afin d'éviter que des paramètres inexistants ne bloquent l'initialisation de MySQL au prochain redémarrage.
Lorsque nous appuyons sur "continuer" pour le changement max_connections, nous recevrons une confirmation qu'il a été appliqué à la configuration et défini au moment de l'exécution à l'aide de SET GLOBAL. Un redémarrage n'est pas nécessaire car max_connections est un paramètre que nous pouvons modifier au moment de l'exécution.
Supposons maintenant que nous voulions modifier la taille du pool de mémoire tampon, cela nécessiterait un redémarrage de MySQL avant que cela ne prenne effet :
Et comme prévu, la valeur a été modifiée dans le fichier de configuration, mais un redémarrage est nécessaire. Vous pouvez le faire en vous connectant manuellement à l'hôte et en redémarrant le processus MySQL. Une autre façon de le faire à partir de ClusterControl consiste à utiliser le tableau de bord des nœuds.
Redémarrage des nœuds dans un cluster Galera
Vous pouvez effectuer un redémarrage par nœud en sélectionnant « Redémarrer le nœud » et en appuyant sur le bouton « Continuer ».
Lorsque vous sélectionnez "Démarrage initial" sur un nœud Galera, ClusterControl vide le répertoire de données MySQL et force une copie complète de cette façon. Ceci est, évidemment, inutile pour un changement de configuration. Assurez-vous de laisser la case "initiale" décochée dans la boîte de dialogue de confirmation. Cela arrêtera et démarrera MySQL sur l'hôte, mais en fonction de votre charge de travail et de la taille du pool de mémoire tampon, cela peut prendre un certain temps, car MySQL commencera à vider les pages modifiées du pool de mémoire tampon InnoDB sur le disque. Ce sont les pages qui ont été modifiées en mémoire mais pas sur disque.
Redémarrage des nœuds dans une topologie MySQL maître-esclave
Pour les topologies maître-esclave MySQL, vous ne pouvez pas simplement redémarrer nœud par nœud. À moins que le temps d'arrêt du maître ne soit acceptable, vous devrez d'abord appliquer les modifications de configuration aux esclaves, puis promouvoir un esclave pour qu'il devienne le nouveau maître.
Vous pouvez parcourir les esclaves un par un et exécuter un "Restart Node" sur eux.
Après avoir appliqué les modifications à tous les esclaves, promouvez un esclave pour qu'il devienne le nouveau maître :
Une fois que l'esclave est devenu le nouveau maître, vous pouvez arrêter et redémarrer l'ancien nœud maître pour appliquer la modification.
Importer des configurations
Maintenant que nous avons appliqué la modification directement sur la base de données, ainsi que sur le fichier de configuration, il faudra attendre la prochaine importation de configuration pour voir la modification reflétée dans la configuration stockée dans ClusterControl. Si vous êtes moins patient, vous pouvez programmer une importation de configuration immédiate en appuyant sur le bouton "Importer".
Gestion de la configuration PostgreSQL
Pour PostgreSQL, la gestion de la configuration fonctionne un peu différemment de la gestion de la configuration MySQL. En général, vous disposez ici des mêmes fonctionnalités :modifier la configuration, importer des configurations pour tous les nœuds et définir/modifier des modèles.
La différence ici est que vous pouvez immédiatement modifier l'intégralité du fichier de configuration et réécrire cette configuration dans le nœud de la base de données.
Si les modifications apportées nécessitent un redémarrage, un bouton "Redémarrer" apparaîtra qui vous permettra de redémarrer le nœud pour appliquer les modifications.
Gestion de la configuration de MongoDB
La gestion de la configuration MongoDB fonctionne de la même manière que la gestion de la configuration MySQL :vous pouvez modifier la configuration, importer des configurations pour tous les nœuds, modifier les paramètres et modifier les modèles.
La modification de la configuration est assez simple, en utilisant la boîte de dialogue Modifier les paramètres (comme décrit dans la section "Modifier les paramètres" ::
Une fois modifié, vous pouvez voir l'action de post-modification proposée par ClusterControl dans la boîte de dialogue "Config Change Log":
Vous pouvez ensuite procéder au redémarrage des nœuds MongoDB respectifs, un nœud à la fois, pour charger les modifications.
Réflexions finales
Dans cet article de blog, nous avons appris comment gérer, modifier et modéliser vos configurations dans ClusterControl. La modification des modèles peut vous faire gagner beaucoup de temps lorsque vous n'avez déployé qu'un seul nœud dans votre topologie. Comme le modèle sera utilisé pour les nouveaux nœuds, cela vous évitera de modifier toutes les configurations par la suite. Cependant, pour les nœuds basés sur MySQL et MongoDB, la modification de la configuration sur tous les nœuds est devenue triviale en raison de la nouvelle interface de gestion de la configuration.
Pour rappel, nous avons récemment abordé dans la même série le déploiement du clustering/réplication (MySQL/Galera, MySQL Replication, MongoDB &PostgreSQL), la gestion &le monitoring de vos bases de données et clusters existants, le monitoring des performances et de la santé, comment rendre votre setup performant disponible via HAProxy et MaxScale et dans le dernier article, comment se préparer aux catastrophes en planifiant des sauvegardes.
