FAQ MongoDBConsultez toutes les FAQ

Cette section répond aux questions sur la mise à l'échelle horizontale en utilisant la fragmentation de MongoDB.

Si vous ne trouvez pas la réponse que vous recherchez, consultez la liste complète des FAQ ou postez votre question dans la liste de diffusion des utilisateurs MongoDB.

Parfois.

Si votre ensemble de données rentre sur un seul serveur, vous devrez commencer avec un déploiement non fragmenté.

La conversion d'une base de données non fragmentée en un cluster fragmenté est facile et homogène, alors il existe un petit avantage à configurer la fragmentation lorsque votre ensemble de données est petit.

Néanmoins, tous les déploiements en production devraient utiliser des replica set pour offrir une haute disponibilité et le recouvrement après panne.

Pour utiliser la réplication avec la fragmentation, déployez chaque fragment comme un replica set.

Non.

Il n'y a pas de soutien automatique dans MongoDB pour modifier une clé de fragment après la fragmentation d'une collection. Cette réalité souligne l'importance de choisir une bonne clé de fragment. Si vous devez modifier une clé après la fragmentation d'une collection, la meilleure option est de :

• vider toutes les données de MongoDB dans un format externe ;
• supprimer la collection originale fragmentée ;
• configurez la fragmentation en utilisant une meilleure clé ;
• prédivisez la portée de la clé de fragment pour assurer une distribution initiale égale ;
• restaurer les données sauvegardées dans MongoDB.
  

Dans l'implémentation actuelle, toutes les bases de données d'un cluster fragmenté ont un « fragment principal ». Toute collection non fragmentée dans cette base de données résidera sur le même fragment.

La fragmentation doit être activée spécifiquement sur une collection. Après l'activation de la fragmentation sur la collection, MongoDB va affecter différentes plages des données de la collection aux différents fragments dans le cluster. Le cluster corrige automatiquement les déséquilibres entre les fragments par la migration des chaînes de données d'un fragment à l'autre.

Le mongos route l'opération vers le « vieux » fragment, où elle va réussir immédiatement. Ensuite, les instances mongod du fragment répliqueront la modification dans le « nouveau » fragment avant que le cluster fragmenté mette à jour « l'appropriation » de ce bloc, ce qui finalise efficacement le processus de migration.

Si un fragment est inaccessible ou indisponible, les requêtes retourneront une erreur.

Cependant, un client peut définir le bit partial de requête, qui retournera alors des résultats de tous les fragments disponibles, indépendamment de savoir si un fragment donné est indisponible.

Si la réponse d'un fragment est lente, les mongos attendront simplement que le fragment retourne les résultats.

Modifié dans la version 2.0.

La méthode exacte pour distribuer les requêtes aux fragments dans un cluster dépend de la nature de la requête et la configuration du cluster fragmenté. Considérez une collection fragmentée, en utilisant la clé de fragmentation user_id, qui a comme attributs last_login et email.

• Pour une requête qui sélectionne une ou plusieurs valeurs pour la clé user_id : le mongos détermine quel(s) fragment ou fragments contiennent les données pertinentes, sur base des métadonnées du cluster, et dirige une requête pour le(s) fragment(s) nécessaire(s), et renvoie ces résultats au client.
• Pour une requête qui sélectionne user_id et effectue également un tri : le mongos peut faire une traduction directe de cette opération dans un certain nombre de requêtes pour les fragments concernés, ordonnés par user_id. Lorsque les requêtes triées retournent tous les fragments, le mongos fusionne les résultats triés et renvoie au client le résultat complet.
• Pour les requêtes qui sélectionnent last_login : ces requêtes doivent être exécutées sur tous les fragments : mongos doit paralléliser la requête sur les fragments et effectuer un tri-fusion sur la valeur email présente dans documents trouvés.
  

Si vous appelez la méthode cursor.sort() sur une requête dans un environnement fragmenté, le mongod de chaque fragment triera ses résultats et le mongos fusionnera les résultats de chaque fragment avant de les retourner au client.

Si vous n'utilisez pas _id comme clé de fragment, alors la responsabilité de garder la valeur du champ _id unique revient à votre couche application/client. Cela pose problème pour des collections qui ont des valeurs _id dupliquées.

Si vous ne fragmentez pas votre collection à l'aide du champ _id, alors vous devriez vous assurer de stocker un identifiant unique global sur ce champ-là. Le BSON ObjectId par défaut fonctionne bien dans ces cas de figure.

Tout d'abord, vérifiez que vous avez bien déclaré une clé de fragmentation pour votre collection. Jusqu'à ce que vous ayez configuré la clé de fragmentation, MongoDB ne créera aucun bloc et la fragmentation n'aura pas lieu.

Ensuite, gardez à l'esprit que la taille par défaut des blocs est de 64 Mo. En conséquence, dans la plupart des situations, la collection doit avoir au moins 64 Mo de données avant qu'une migration se produise.

De plus, le système qui équilibre les blocs entre serveurs tente d'éviter les migrations superflues. Selon le nombre de fragments, votre clé de fragmentation et la quantité de données, les systèmes exigent souvent au moins 10 blocs de données pour déclencher les migrations.

Vous pouvez exécuter db.printShardingStatus() pour voir tous les blocs présents dans votre cluster.

Oui. mongod crée ces fichiers en tant que sauvegardes pendant les opérations usuelles d'équilibrage des fragments. Si des erreurs apparaissent lors d'une migration, ces fichiers peuvent être utiles pour la récupération des documents concernés par la migration.

Une fois que la migration a réussi et il n'y a aucune nécessité de récupérer des documents à partir de ces fichiers, vous pouvez les supprimer en toute sécurité. Ou, si vous disposez d'une sauvegarde de la base de données que vous pouvez utiliser pour la récupération, vous pouvez également supprimer ces fichiers après la migration.

Pour déterminer si toutes les migrations sont complètes, exécutez sh.isBalancerRunning() tout en étant connecté à une instance mongos.

mongos utilise un ensemble de pools de connexion pour communiquer avec chaque fragment. Ces pools ne rétrécissent pas quand le nombre de clients diminue.

Cela peut conduire à un mongosmongos inutilisé avec un grand nombre de connexions ouvertes. Si le n'est plus en cours d'utilisation, il est sûr de redémarrer le processus pour fermer les connexions existantes.

Connectez-vous à mongos avec le shell mongo, et exécutez la commande suivante :

db._adminCommand("connPoolStats");

L'écouteur d'écriture différée est un processus qui ouvre un long pool pour relayer les écritures de retour d'un mongod ou mongos après migrations, afin de vous assurer qu'ils ne sont pas allés sur le mauvais serveur. L'écouteur d'écriture différée envoie les écritures vers le bon serveur si nécessaire.

Ces messages sont un élément clé de l'infrastructure de fragmentation et ne devraient pas vous inquiéter.

Les migrations échouées ne nécessitent aucune intervention administrative. Les migrations des blocs conservent toujours un état cohérent. Si une migration ne parvient pas à s'achever pour une raison quelconque, le cluster réessaie l'opération. Lorsque la migration s'est bien terminée, les données résident uniquement sur le nouveau fragment.

Voir Le tutoriel sur les clusters fragmentés pour plus d'informations sur la migration ou le replacement des serveurs de configuration.

Les instances mongos maintiennent un cache de la base de données config qui contient les métadonnées pour le cluster fragmenté. Ces métadonnées comprennent la cartographie des chunks vers des fragments.

mongos met à jour son cache paresseusement par l'émission d'une requête vers un fragment et découvrant que ses métadonnées sont obsolètes. Il n'y a pas moyen de contrôler ce comportement depuis le client, mais vous pouvez exécuter la commande flushRouterConfig sur n'importe quel mongos pour le forcer à rafraîchir son cache.

Les instances mongosmongos vont détecter ces changements au fil du temps sans intervention. Toutefois, si vous voulez forcer les à recharger leur configuration, exécutez la commande flushRouterConfig directement sur chaque mongos.

L'option maxIncomingConnections limite le nombre de connexions acceptées par les mongos.

Ceci est particulièrement utile pour un mongos si vous avez un client qui crée des connexions multiples et leur permet de dépasser le délai plutôt que de les fermer.

Dans ce cas, configurez maxIncomingConnections à une valeur légèrement supérieure au nombre maximal de connexions que le client crée, ou à la taille maximale du pool de connexion.

Ce paramètre empêche les mongos de causer des pointes de connexion sur les fragments individuels. Ces pointes peuvent perturber le fonctionnement et l'allocation du cluster fragmenté.

Si la requête n'inclut pas la clé de fragmentation, les mongos doivent envoyer la requête à tous les fragments comme une opération « disperser/regrouper ». Chaque fragment va, à son tour, utiliser soit l'indice de clé de fragment, soit un autre indice plus efficace pour accomplir la requête.

Si la requête inclut plusieurs sous-expressions qui référencent les champs indexés par la clé de fragmentation et l'index secondaire, les mongos peuvent router les requêtes vers un fragment particulier et ce dernier utilisera l'index qui leur permettra de s'accomplir le plus efficacement possible. Voir cette présentation pour plus d'informations.

Les clés de fragmentation peuvent être aléatoires. Les clés aléatoires assurent une distribution optimale des données à travers le cluster.

Les clusters fragmentés tentent de router les requêtes vers des fragments spécifiques lorsque celles-ci contiennent la clé de fragmentation comme paramètre, car ces requêtes directes sont plus efficaces. Dans de nombreux cas, les clés aléatoires peuvent rendre difficiles les requêtes directes vers des fragments spécifiques.

Oui. Il n'y a aucune exigence que les documents soient distribués de manière uniforme par la clé de fragmentation.

Toutefois, les documents qui ont la même clé de fragmentation doivent résider dans le même bloc, et donc sur le même serveur. Si votre ensemble de données fragmentées a trop de documents avec exactement la même clé de fragment vous ne serez pas en mesure de distribuer ces documents dans votre cluster fragmenté.

Vous pouvez utiliser n'importe quel champ comme clé de fragmentation. Le champ _id est une clé de fragmentation usuelle.

Soyez conscient que les valeurs ObjectId(), qui sont la valeur par défaut du champ _id, sont incrémentées comme un timestamp. Par conséquent, lorsque ce champ est utilisé comme une clé de fragmentation, tous les nouveaux documents insérés dans la collection appartiendront d'abord au même bloc d'un seul fragment. Bien que le système finira par diviser ce bloc et faire migrer son contenu pour distribuer des données de façon plus uniforme, à un certain moment le cluster peut effectuer uniquement des opérations d'insertion directe dans un seul fragment. Cela peut limiter le débit d'insertions. Si la plupart de vos opérations d'écriture sont des mises à jour, cette limitation ne devrait pas affecter votre performance. Cependant, si vous avez un volume élevé d'insertions, cela peut être une limitation.

Pour résoudre ce problème, MongoDB 2.4 fournit des clés de fragmentation hachées.

À la fin de la migration d'un bloc, le fragment doit se connecter à la base de données config pour mettre à jour l'enregistrement du bloc dans les métadonnées du cluster. Si le fragment ne parvient pas à se connecter à la base de données config, MongoDB signale l'erreur suivante :

	ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"

Le processus d'équilibrage des clusters fragmentés contrôle tant les blocs migrant à partir de fragments déclassés (par exemple, draining) que les activités normales d'équilibrage de clusters. Considérez les comportements suivants pour les différentes versions de MongoDB dans des situations où vous supprimez un fragment dans un cluster avec une distribution de bloc inégale :

• à partir de MongoDB 2.2, l'équilibreur supprime d'abord les blocs du fragment drainé, puis équilibre la répartition inégale du bloc restant ;
• avant MongoDB 2.2, l'équilibreur gère la distribution inégale de bloc, puis supprime les blocs du fragment drainé.