FAQ MongoDBConsultez toutes les FAQ

Les deux facteurs les plus importants dans le maintien d'un cluster fragmenté opérationnel sont :

• le choix d'une clé de partitionnement appropriée et
• une capacité suffisante pour soutenir les opérations actuelles et futures.
  

Votre cluster doit avoir suffisamment de données pour que la fragmentation ait du sens. La fragmentation fonctionne par la migration des chunks entre fragments jusqu'à ce que chaque fragment a à peu près le même nombre de chunks.

La taille de chunk par défaut est de 64 mégaoctets. MongoDB ne commencera pas les migrations jusqu'à ce que le déséquilibre des morceaux dans le cluster dépasse le seuil de migration. Bien que la taille par défaut du chunk est configurable via le paramètre chunkSize, ces comportements aident à prévenir les migrations de chunks inutiles, ce qui peut dégrader les performances de votre cluster dans son ensemble.

Si vous avez juste déployé un cluster fragmenté, assurez-vous que vous avez suffisamment de données pour rendre la fragmentation effective. Si vous ne disposez pas de suffisamment de données pour créer plus de huit chunks de 64 mégaoctets, alors toutes les données resteront sur un fragment. Soit diminuez le paramètre taille de chunk, soit ajoutez plus des données au cluster.

Comme un problème lié, le système va diviser les chunks uniquement sur des insert ou des update, ce qui signifie que si vous configurez la fragmentation et ne continuez pas à exécuter des opérations INSERT et UPDATE, la base de données ne créera aucun chunk. Vous pouvez attendre jusqu'à ce que votre application insère des données ou diviser les chunks manuellement.

Enfin, si votre clé de fragmentation a une cardinalité faible, MongoDB pourrait ne pas être en mesure de créer suffisamment de divisions parmi les données.

Dans certaines situations, un seul fragment ou un sous-ensemble du cluster recevront une partie disproportionnée de trafic et de charge de travail. Dans la plupart des cas, ceci est le résultat d'une clé de fragment qui ne permet pas efficacement la mise à l'échelle de l'écriture.

Il est également possible que vous ayez des « chunks chauds ». Dans ce cas, vous pourriez être en mesure de résoudre le problème par le fractionnement suivi de la migration de parties de ces chunks.

Dans le pire des cas, vous pourriez devoir envisager une nouvelle fragmentation de vos données et choisir une clé de fragmentation différente pour corriger cette tendance.

Si vous venez de déployer votre cluster fragmenté, vous voudrez peut-être examiner les suggestions de dépannage pour un nouveau cluster où les données restent sur un seul fragment.

Si le cluster était initialement équilibré, mais qu'il a développé plus tard une répartition inégale des données, examinez les causes possibles suivantes :

• vous avez supprimé ou retiré du cluster une quantité importante de données. Si vous avez ajouté des données supplémentaires, elles peuvent avoir une répartition différente en ce qui concerne leur clé de fragment;
• votre clé de fragment a une cardinalité faible et MongoDB ne peut plus continuer à diviser les chunks ;
• votre ensemble de données croît plus vite que la vitesse de distribution des données dans le cluster par l'équilibreur. Cela est rare et est généralement le résultat de :
  
  
  • une fenêtre d'équilibrage qui est trop courte par rapport au taux de croissance des données,
  • une répartition inégale des opérations d'écriture qui nécessitent plus de migration de données. Vous pourriez avoir à choisir une clé de fragment différente pour résoudre ce problème,
  • faible connectivité réseau entre fragments, ce qui peut conduire à des migrations de chunks qui prennent trop de temps pour s'achever. Examinez la configuration de votre réseau et les interconnexions entre fragments.

Si les migrations affectent votre cluster ou les performances de l'application, envisagez les options suivantes, en fonction de la nature de l'impact :

• Si les migrations interrompent juste sporadiquement votre cluster, vous pouvez limiter la fenêtre d'équilibrage pour empêcher l'activité d'équilibrage pendant les heures de pointe. Assurez-vous qu'il reste assez de temps pour éviter que les données soient à nouveau déséquilibrées ;
• Si l'équilibreur fait toujours migrer des chunks au détriment de la performance globale du cluster :
  
  
  • vous pouvez vouloir tenter de diminuer la taille du chunk afin de limiter la taille de la migration,
  • votre cluster peut être en surcapacité, et vous voudrez peut-être tenter d'ajouter un ou deux fragments au cluster, pour répartir la charge.