Dépannage d'un cluster partagé MongoDB

Sélectionner les clés de partition et la disponibilité du cluster

Le partitionnement consiste à diviser les données en petits groupes appelés fragments afin de réduire la charge de travail globale pour un débit donné opération. Ce regroupement est réalisé en sélectionnant une clé optimale qui est principalement la partie la plus importante avant le sharding. Une clé optimale doit garantir :

1. Mongos peut isoler la plupart des requêtes vers un mongod spécifique. Si, par exemple, plusieurs opérations sont soumises à un seul fragment, la défaillance de ce fragment ne fera que rendre les données qui lui sont associées absentes à ce moment-là. Il est conseillé de sélectionner une clé de partition qui donnera plus de partitions pour réduire la quantité de données indisponibles en cas de panne de la partition.
2. MongoDB pourra répartir les données de manière égale entre les morceaux. Cela garantit que les opérations de débit seront également réparties uniformément, ce qui réduit les risques d'échec en raison d'une charge de travail accrue.
3. Évolutivité en écriture sur l'ensemble du cluster pour garantir une haute disponibilité. Chaque fragment doit être un jeu de répliques dans la mesure où si une certaine instance mongod échoue, les membres restants du jeu de répliques sont capables d'élire un autre membre comme primaire, assurant ainsi la continuité opérationnelle.

Si, dans tous les cas, un fragment donné a tendance à échouer, commencez par vérifier le nombre d'opérations de débit est-il soumis à et envisagez de sélectionner une meilleure clé de partitionnement pour avoir plus de fragments.

Et si ? L'instance de Mongos devient absente

Vérifiez d'abord si vous vous connectez au bon port car vous avez peut-être changé sans le savoir. Par exemple, lors du déploiement avec la plate-forme AWS, il est probable que ce problème se produise en raison des groupes de sécurité qui peuvent ne pas autoriser les connexions sur ce port. Pour un test immédiat, essayez de spécifier le host:port complet pour vous assurer que vous utilisez une interface de bouclage. La bonne chose est que si chaque serveur d'application a sa propre instance mongos, les serveurs d'application peuvent continuer à accéder à la base de données. De plus, les instances mongos voient leurs états altérés avec le temps et peuvent redémarrer sans nécessairement perdre de données. Lorsque l'instance est reconnectée, elle récupère une copie de la base de données de configuration et commence à acheminer les requêtes.

Assurez-vous que le port sur lequel vous essayez de vous reconnecter n'est pas non plus occupé par un autre processus.

Et si ? Un membre devient absent de l'ensemble de répliques de fragments

Commencez par vérifier l'état du fragment en exécutant la commande sh.status(). Si le résultat renvoyé n'a pas le clusterId, le fragment est en effet indisponible. Enquêtez toujours sur les interruptions et les pannes de disponibilité et si vous ne parvenez pas à le récupérer dans les plus brefs délais, créez un nouveau membre pour le remplacer dès que possible afin d'éviter davantage de pertes de données.

Si un membre secondaire devient indisponible mais avec des entrées oplog actuelles, lorsqu'il est reconnecté, il peut rattraper le dernier état défini en lisant les données actuelles de l'oplog en tant que processus de réplication normal. S'il ne parvient pas à répliquer les données, vous devez effectuer une synchronisation initiale à l'aide de l'une de ces deux options...

1. Redémarrez mongod avec un répertoire de données vide et laissez la fonction de synchronisation initiale normale de MongoDB restaurer les données. Cependant, cette approche prend beaucoup de temps pour copier les données, mais assez simple.
2. Redémarrez la machine hôte avec une copie d'un répertoire de données récent d'un autre membre du jeu de répliques. Processus rapide mais avec des étapes compliquées

La synchronisation initiale permettra à MongoDB de...

1. Cloner toutes les bases de données disponibles sauf la base de données locale. Assurez-vous que le membre cible dispose de suffisamment d'espace disque dans la base de données locale pour stocker temporairement les enregistrements oplog pendant la durée de copie des données.
2. Appliquer toutes les modifications à l'ensemble de données en utilisant l'oplog de la source. Le processus ne sera terminé que si le statut du réplica passe de STARTUP2 à SECONDARY.

Et si ? Tous les membres d'un ensemble de répliques sont absents

Les données contenues dans une partition seront indisponibles si tous les membres d'une partition d'ensemble de répliques deviennent absents. Étant donné que les autres fragments restent disponibles, les opérations de lecture et d'écriture sont toujours possibles, sauf que l'application sera servie avec des données partielles. Vous devrez rechercher la cause des interruptions et tenter de réactiver le fragment dès que possible. Vérifiez quel profileur de requête ou la méthode d'explication pourrait avoir conduit à ce problème.

Et si ? Les données de configuration obsolètes entraînent des échecs de curseur

Parfois, une instance mongos peut mettre longtemps à mettre à jour le cache de métadonnées à partir de la base de données de configuration, ce qui entraîne le retour d'une requête l'avertissement : 

could not initialize cursor across all shards because : stale config detected

Cette erreur sera toujours présentée jusqu'à ce que les instances mongos actualisent leurs caches. Cela ne doit pas se propager à l'application. Pour résoudre ce problème, vous devez forcer l'actualisation de l'instance en exécutant fluRouterConfig.

Pour vider le cache pour une exécution de collecte spécifique

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Pour vider le cache pour une exécution de base de données spécifique 

db.adminCommand({ flushRouterConfig: "<db>" } )

Pour vider le cache de toutes les bases de données et de leurs collections, exécutez :

db.adminCommand("flushRouterConfig")

db.adminCommand( { flushRouterConfig: 1 } )

Et si ? Le serveur de configuration devient indisponible

Le serveur de configuration dans ce cas peut être considéré comme le membre principal à partir duquel les nœuds secondaires répliquent leurs données. S'il devient absent, les nœuds secondaires disponibles devront élire un parmi leurs membres pour devenir le primaire. Pour éviter de vous retrouver dans une situation où vous ne disposez peut-être pas d'un serveur de configuration, envisagez de répartir les membres du jeu d'instances dupliquées sur deux centres de données puisque...

• Si un centre de données tombe en panne, les données seront toujours disponibles pour des lectures plutôt qu'aucune opération si vous avez utilisé un seul centre de données .
• Si le centre de données qui implique des membres minoritaires tombe en panne, le jeu de répliques peut toujours servir à la fois aux opérations d'écriture et de lecture.

Il est conseillé de répartir les membres sur au moins trois centres de données.

Une autre possibilité de distribution consiste à répartir uniformément les membres porteurs de données entre les deux centres de données et les membres restants dans le nuage.

Correction de l'erreur de chaîne de base de données

Depuis MongoDB 3.4, les serveurs de configuration SCCC ne sont pas pris en charge pour les instances mongod en miroir. Si vous devez mettre à niveau votre cluster partitionné vers la version 3.4, vous devez convertir les serveurs de configuration de SCCC en CSRS.

Éviter les temps d'arrêt lors du déplacement des serveurs de configuration

Les temps d'arrêt peuvent survenir en raison de certains facteurs tels qu'une panne de courant ou les fréquences du réseau, entraînant ainsi le défaillance d'un serveur de configuration au cluster. Utilisez CNAME pour identifier ce serveur afin de le renommer ou de le renuméroter lors de la reconnexion. Si la commande moveChunk commit échoue pendant le processus de migration, MongoDB signalera l'erreur :

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of

<N>|<NN>" and "ERROR: TERMINATING"

Cela signifie que le fragment n'a pas non plus été connecté à la base de données de configuration, donc le primaire mettra fin à ce membre pour éviter l'incohérence des données. Vous devez résoudre l'échec de la migration de bloc indépendamment en consultant le support MongoDB. Assurez-vous également de fournir des ressources stables telles que le réseau et l'alimentation du cluster.

Conclusion

Un cluster fragmenté MongoDB réduit la charge de travail sur laquelle un seul serveur aurait été soumis, améliorant ainsi les performances des opérations de débit. Cependant, le fait de ne pas configurer correctement certains paramètres, comme la sélection d'une clé de partition optimale, peut créer un déséquilibre de charge, d'où l'échec de certaines partitions.

En supposant que la configuration est effectuée correctement, certains revers inévitables tels que des pannes de courant peuvent également survenir. Pour continuer à prendre en charge votre application avec un temps d'arrêt minimal, envisagez d'utiliser au moins 3 centres de données. Si l'un échoue, les autres seront disponibles pour prendre en charge les opérations de lecture si le principal figure parmi les membres concernés. Mettez également à niveau votre système vers au moins la version 3.4, car il prend en charge davantage de fonctionnalités.