MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Fonctionnalités MongoDB dans ClusterControl 1.4

Notre dernière version de ClusterControl transforme certaines des tâches MongoDB les plus gênantes en un travail de seulement 15 secondes. De nouvelles fonctionnalités ont été ajoutées pour vous donner plus de contrôle sur votre cluster et effectuer des changements de topologie :

  • Convertir un replicaSet MongoDB en un cluster MongoDB partitionné
  • Ajouter et supprimer des partitions
  • Ajouter des routeurs de partition à un cluster MongoDB partitionné
  • Réduire ou geler un nœud
  • Nouveaux conseillers MongoDB

Nous décrirons ces fonctionnalités ajoutées en détail ci-dessous.

Convertir un ReplicaSet MongoDB en cluster MongoDB partagé

Comme la plupart des utilisateurs de MongoDB commenceront avec un replicaSet pour stocker leur base de données, il s'agit du type de cluster le plus fréquemment utilisé. Si vous rencontrez des problèmes de mise à l'échelle, vous pouvez mettre à l'échelle ce jeu de répliques en ajoutant plus de secondaires ou en effectuant une mise à l'échelle par partitionnement. Vous pouvez convertir un replicaSet existant en un cluster fragmenté, mais il s'agit d'un long processus où vous pourriez facilement faire des erreurs. Dans ClusterControl, nous avons automatisé ce processus, où nous ajoutons automatiquement les serveurs de configuration, les routeurs de partitionnement et activons le partitionnement.

Pour convertir un replicaSet en un cluster fragmenté, vous pouvez simplement le déclencher via le menu déroulant des actions :

Cela ouvrira un dialogue en deux étapes sur la façon de convertir cela en un fragment. La première étape consiste à définir où déployer le serveur de configuration et les routeurs de partition :

La deuxième étape consiste à savoir où stocker les données et quels fichiers de configuration doivent être utilisés pour le serveur de configuration et le routeur de partition.

Une fois la tâche de migration de partition terminée, la vue d'ensemble du cluster affiche désormais les partitions au lieu des instances replicaSet :

Après la conversion en cluster fragmenté, de nouveaux fragments peuvent être ajoutés.

Ajouter ou supprimer des partitions d'un cluster MongoDB partitionné

Ajouter des fragments

Comme un fragment MongoDB est techniquement un replicaSet, l'ajout d'un nouveau fragment implique également le déploiement d'un nouveau replicaSet. Dans ClusterControl, nous déployons d'abord un nouveau replicaSet, puis nous l'ajoutons au cluster fragmenté.

À partir de l'interface utilisateur de ClusterControl, vous pouvez facilement ajouter de nouvelles partitions grâce à un assistant en deux étapes, ouvert à partir du menu déroulant des actions :

Ici, vous pouvez définir la topologie de la nouvelle partition.

Une fois le nouveau fragment ajouté au cluster, le routeur de fragments MongoDB commencera à lui attribuer de nouveaux fragments, et l'équilibreur équilibrera automatiquement tous les fragments sur tous les fragments.

Supprimer des fragments

Supprimer des fragments est un peu plus difficile que d'ajouter un fragment, car cela implique de déplacer les données vers les autres fragments avant de supprimer le fragment lui-même. Pour toutes les données qui ont été partitionnées sur tous les fragments, ce sera un travail effectué par l'équilibreur MongoDB.

Cependant, toute base de données/collection non partitionnée, à laquelle cette partition a été attribuée comme partition principale, doit être déplacée vers une autre partition et devenir sa nouvelle partition principale. Pour ce processus, MongoDB doit savoir où déplacer ces bases de données/collections non partitionnées.

Dans ClusterControl, vous pouvez simplement les supprimer via le menu déroulant des actions :

Cela vous permettra de sélectionner la partition que vous souhaitez supprimer et la partition vers laquelle vous souhaitez migrer les bases de données principales :

Le travail qui supprime le fragment effectuera alors des actions similaires à celles décrites précédemment :il déplacera toutes les bases de données primaires vers le fragment désigné, activera l'équilibreur, puis attendra qu'il déplace toutes les données du fragment.

Une fois toutes les données supprimées, le fragment sera supprimé de l'interface utilisateur.

Ajout de routeurs de fragments MongoDB supplémentaires

Une fois que vous aurez commencé à faire évoluer votre application à l'aide d'un cluster partitionné MongoDB, vous aurez peut-être besoin de routeurs de partition supplémentaires.

L'ajout de routeurs de partition MongoDB supplémentaires est un processus très simple avec ClusterControl, il suffit d'ouvrir la boîte de dialogue Ajouter un nœud à partir du menu déroulant des actions :

Cela ajoutera un nouveau routeur de partition au cluster. N'oubliez pas de définir le bon port par défaut (27017) sur le routeur.

Réduire le serveur

Si vous souhaitez effectuer une maintenance sur le nœud principal d'un replicaSet, il est préférable de le faire d'abord « descendre » de manière gracieuse avant de le mettre hors ligne. La suppression d'un primaire signifie essentiellement que l'hôte cesse d'être un primaire et devient un secondaire et n'est pas éligible pour devenir un primaire pendant un nombre défini de secondes. Les nœuds du replicaSet MongoDB avec pouvoir de vote éliront un nouveau primaire avec le primaire réduit exclu pendant le nombre de secondes défini.

Dans ClusterControl, nous avons ajouté la fonctionnalité de descente en tant qu'action sur la page Nœuds. Pour vous retirer, sélectionnez simplement ceci comme action dans le menu déroulant :

Après avoir défini le nombre de secondes pour le retrait et confirmé, le primaire se retirera et un nouveau primaire sera élu.

Geler un nœud

Cette fonctionnalité est similaire à la commande step down :cela rend un certain nœud inéligible pour devenir un nœud principal pendant un nombre défini de secondes. Cela signifie que vous pouvez empêcher un ou plusieurs nœuds secondaires de devenir un nœud principal lors de la suppression du nœud principal et forcer un certain nœud à devenir le nouveau nœud principal de cette façon.

Dans ClusterControl, nous avons ajouté la fonctionnalité de blocage du nœud en tant qu'action sur la page Nœuds. Pour geler un nœud, sélectionnez-le simplement comme action dans le menu déroulant :

Après avoir défini le nombre de secondes et confirmé, le nœud ne sera pas éligible en tant que nœud principal pendant le nombre de secondes défini.

Nouveaux conseillers MongoDB

Les conseillers sont des mini-programmes qui fournissent des conseils sur des problèmes de base de données spécifiques. Nous avons ajouté  trois nouveaux conseillers pour MongoDB. Le premier calcule la fenêtre de réplication, le second surveille la fenêtre de réplication et le troisième vérifie les bases de données/collections non partitionnées.

Conseiller de décalage de réplication MongoDB

Il est très important de garder un œil sur le décalage de réplication si vous augmentez les lectures en ajoutant plus de secondaires. MongoDB n'utilisera ces secondaires que s'ils ne sont pas trop à la traîne. Si le secondaire présente un décalage de réplication, vous risquez de diffuser des données obsolètes qui ont déjà été écrasées sur le principal.

Pour vérifier le lag de réplication, il suffit de se connecter au primaire et de récupérer ces données à l'aide de la commande replSetGetStatus. Contrairement à MySQL, le primaire garde une trace de l'état de réplication de ses secondaires.

Nous avons implémenté cette vérification dans un conseiller dans ClusterControl, pour nous assurer que votre retard de réplication sera toujours surveillé.

Conseiller de fenêtre de réplication MongoDB

Tout comme le décalage de réplication, la fenêtre de réplication est une mesure tout aussi importante à examiner. Le conseiller de décalage nous informe déjà du nombre de secondes pendant lesquelles un nœud secondaire est derrière le nœud principal/maître. Comme l'oplog est limité en taille, avoir un décalage esclave impose les risques suivants :

  1. Si un nœud est trop en retard, il peut ne plus être en mesure de rattraper son retard car les transactions nécessaires pour rattraper son retard ne sont plus dans l'oplog du primaire.
  2. Un nœud secondaire en retard est moins favorisé lors d'une élection MongoDB pour un nouveau nœud principal. Si tous les secondaires sont en retard dans la réplication, vous aurez un problème et celui avec le moins de retard deviendra primaire.
  3. Les secondaires en retard sont moins favorisés par le pilote MongoDB lors de la mise à l'échelle des lectures avec MongoDB, cela ajoute également une charge de travail plus élevée sur les secondaires restants.

Si nous avions un nœud secondaire en retard de quelques minutes (ou heures), il serait utile d'avoir un conseiller qui nous informe du temps qu'il nous reste avant que notre prochaine transaction ne soit supprimée de l'oplog. La différence de temps entre la première et la dernière entrée dans l'oplog s'appelle la fenêtre de réplication. Cette métrique peut être créée en récupérant le premier et le dernier élément de l'oplog et en calculant la différence de leurs horodatages.

Dans le shell MongoDB, il existe déjà une fonction disponible qui calcule la fenêtre de réplication pour vous. Cependant, cette fonction est intégrée au shell de ligne de commande, de sorte que toute connexion extérieure n'utilisant pas le shell de ligne de commande n'aura pas cette fonction intégrée. C'est pourquoi nous avons créé un conseiller qui surveillera la fenêtre de réplication et vous avertira si vous dépassez un seuil prédéfini.

Conseiller en bases de données et collections non partitionnées MongoDB

Les bases de données et les collections non partitionnées seront affectées à une partition principale par défaut par le routeur de partition MongoDB. Cela signifie que la base de données ou la collection est limitée à la taille de ce fragment principal et, si elle est écrite en gros volumes, peut utiliser tout l'espace disque restant d'un fragment. Une fois que cela se produit, le fragment ne fonctionnera évidemment plus. Par conséquent, il est important de surveiller toutes les bases de données et collections existantes et d'analyser la base de données de configuration pour valider qu'elles ont été activées pour le partitionnement.

Pour éviter que cela ne se produise, nous avons créé une base de données non partitionnée et un conseiller de collecte. Ce conseiller analysera chaque base de données et collection, et vous avertira si elle n'a pas été fragmentée.

ClusterControl a amélioré la maintenabilité de MongoDB

Nous avons fait un grand pas en ajoutant toutes les améliorations apportées à ClusterControl pour les replicaSets MongoDB et les clusters fragmentés. Cela améliore considérablement la convivialité de MongoDB et permet aux DBA, sysops et devops de mieux gérer leurs clusters !