Wir haben ein relativ einfaches sharded MongoDB-Setup: 4 Shards, wobei jedes Shard ein Replikat-Set mit mindestens 3 Mitgliedern ist. Jede Sammlung besteht aus Daten, die aus vielen Dateien geladen werden. Jede Datei erhält eine monoton ansteigende ID und das Sharding wird basierend auf einem Hash der ID durchgeführt.
Die meisten unserer Kollektionen funktionieren wie erwartet. Allerdings habe ich eine Sammlung, die die Chunks nicht korrekt über Shards verteilt. Die Sammlung hatte ~ 30GB Daten, die geladen wurden, bevor der Index erstellt wurde, und es wurde geschichtet, aber das sollte, soweit ich weiß, nicht wichtig sein. Hier sind die Statistiken für die Sammlung:
%Vor%Und der sh.status () für diese Sammlung:
%Vor%Gibt es etwas, was mir fehlt, warum diese Sammlung nur an rs0 verteilt wird? Gibt es eine Möglichkeit, eine Neugewichtung zu erzwingen? Ich führte die gleichen Schritte durch, um andere Sammlungen zu kopieren und sie verteilten sich richtig. Hier sind die Statistiken für eine Sammlung, die erfolgreich erstellt wurde:
%Vor%sh.status () für die ordnungsgemäß erstellte Sammlung:
%Vor%Wenn Sie in MongoDB zu einem sharded-System gehen und kein Balancing sehen, könnte es eines von mehreren Dingen geben.
Sie haben möglicherweise nicht genügend Daten, um den Ausgleich auszulösen. Das war definitiv nicht Ihre Situation, aber manche Leute wissen vielleicht nicht, dass es bei einer Standard-Chunk-Größe von 64MB eine Weile dauern kann, bis Daten vorhanden sind, um genug zu teilen und einen Teil davon auf andere Chunks auszubalancieren.
Der Balancer wurde möglicherweise nicht ausgeführt - da Ihre anderen Sammlungen ausgeglichen wurden, war das in Ihrem Fall unwahrscheinlich, es sei denn, diese Sammlung wurde zuletzt geschaltet, nachdem der Balancer aus irgendeinem Grund gestoppt wurde.
Die Stücke in Ihrer Sammlung können nicht verschoben werden. Dies kann passieren, wenn der Shard-Schlüssel nicht granular genug ist, um die Daten in kleine Stücke aufzuteilen. Es stellte sich heraus, dass dies der Fall war, weil Ihr Shard-Schlüssel für diese große Sammlung nicht granular genug war - Sie haben 105 Chunks (was wahrscheinlich der Anzahl der eindeutigen job_id-Werte entspricht) und über 30 GB Daten. Wenn die Chunks zu groß sind und der Balancer sie nicht bewegen kann, werden sie als "Jumbo" gekennzeichnet (so dass die Räder nicht gedreht werden, wenn versucht wird, sie zu migrieren).
Wie erholt man sich von einer schlechten Wahl eines Shard-Schlüssels? Normalerweise ist es sehr schmerzhaft, den Shard-Schlüssel zu ändern - da der Shard-Schlüssel unveränderlich ist, müssen Sie eine vollständige Datenmigration durchführen, um sie in eine Sammlung mit einem anderen Shard-Schlüssel zu bekommen. In Ihrem Fall befindet sich die Sammlung jedoch immer noch auf einem Shard, so dass es relativ einfach sein sollte, die Sammlung zu "entschärfen" und sie mit einem neuen Shard-Schlüssel zu überarbeiten. Da die Anzahl der job_ids relativ klein ist, würde ich empfehlen, einen regulären Index für shard bei job_id, customer_code zu verwenden, da Sie wahrscheinlich danach fragen, und ich nehme an, dass es immer zum Zeitpunkt der Dokumentenerstellung gesetzt ist.