Mise à jour: avril 2018
Cette réponse était correcte au moment de la question, mais les choses ont évolué depuis lors. Depuis la version 3.4, le parallélisme a été introduit et le ticket que j'ai référencé à l'origine a été fermé. Pour plus d'informations, je couvre certains des détails dans cette réponse plus récente . Je laisserai le reste de la réponse tel quel car il reste une bonne référence pour les problèmes / contraintes générales ainsi que valable pour toute personne sur une version plus ancienne.
Réponse originale
Je donne une explication complète de ce qui se passe avec une migration de morceau dans le M202 Cours avancé si vous êtes intéressé. En termes généraux, disons simplement que les migrations ne sont pas très rapides, même pour des morceaux vides, en raison du nettoyage effectué pour s'assurer que les migrations fonctionnent dans un système actif (elles se produisent toujours même si rien d'autre que l'équilibrage ne se produit).
De plus, il n'y a qu'une seule migration à la fois sur l'ensemble du cluster - il n'y a pas de parallélisme. Ainsi, malgré le fait que vous ayez deux nœuds "pleins" et deux nœuds "vides", à tout moment, il y a au plus une migration (entre le fragment avec le plus de morceaux et le fragment avec le moins). Par conséquent, l'ajout de 2 fragments ne vous rapporte rien en termes de vitesse d'équilibrage et augmente simplement le nombre de morceaux à déplacer.
Pour les migrations elles-mêmes, les morceaux ont probablement une taille d'environ 30 Mo (cela dépend de la façon dont vous avez rempli les données, mais généralement ce sera votre moyenne avec la taille de bloc maximale par défaut). Vous pouvez exécuter db.collection.getShardDistribution()pour certaines de ces informations, et voir ma réponse ici pour des moyens d'obtenir encore plus d'informations sur vos morceaux.
Puisqu'il n'y a aucune autre activité en cours, pour qu'une migration se produise, le fragment cible (l'un des nouveaux fragments ajoutés) devra lire ~ 30 Mo de données à partir des fragments source (l'un des 2 originaux) et mettre à jour les serveurs de configuration vers refléter le nouvel emplacement de bloc une fois qu'il est terminé. Le déplacement de 30 Mo de données ne devrait pas constituer un goulot d'étranglement pour un système normal sans charge.
S'il est lent, il y a plusieurs raisons possibles à cela, mais les plus courantes pour un système qui n'est pas occupé sont:
- E / S du disque source - si les données ne sont pas dans la mémoire active lors de leur lecture, elles doivent être paginées à partir du disque
- Réseau - en cas de latence, de limitation de débit, de perte de paquets, etc., la lecture peut prendre un certain temps
- E / S disque cible - les données et les index doivent être écrits sur le disque, de nombreux index peuvent aggraver la situation, mais généralement ce n'est pas un problème sur un système légèrement chargé
- Problèmes de migrations entraînant des abandons et des échecs de migration (problèmes avec les serveurs de configuration, problèmes avec les suppressions sur les primaires)
- Délai de réplication - pour les migrations vers des jeux de réplicas, problème d'écriture
w:2ou w:majorityest utilisé par défaut et nécessite des secondaires à jour pour le satisfaire.
Si le système était occupé, alors la contention de la mémoire, la contention de verrouillage serait généralement suspecte ici aussi.
Pour obtenir plus d'informations sur la durée des migrations, en cas d'échec, etc., consultez les entrées dans votre config.changelog:
// connect to mongos
use config
db.changelog.find()
Comme vous l'avez vu, et comme je le dis généralement aux gens quand je fais de la formation / éducation, si vous savez que vous aurez besoin de 4 fragments, il est généralement préférable de commencer par 4 plutôt que de monter en puissance. Si vous le faites, alors vous devez être conscient que l'ajout d'un fragment peut prendre beaucoup de temps, et est initialement un net négatif sur les ressources plutôt qu'un gain (voir la partie II de ma série de pièges de partage pour une discussion plus détaillée à ce sujet).
Enfin, pour suivre / voter / commenter la demande de fonctionnalité afin d'améliorer le parallélisme des migrations de blocs, consultez SERVER-4355