2012-08-30 8 views
6

Ich habe einen Mongo Cluster mit 2 Shards, RS1 und RS2. RS1 hat ungefähr 600G (*), RS2 ungefähr 460G. Vor ein paar Minuten habe ich einen neuen Shard, RS3, hinzugefügt. Wenn ich eine Verbindung Status Mongos und zu überprüfen, hier ist das, was ich sehe:MongoDB: neuer Shard wird angezeigt, zeigt jedoch keinen Inhalt an. Wird das erwartet?

mongos> db.printShardingStatus() 
--- Sharding Status --- 
    sharding version: { "_id" : 1, "version" : 3 } 
    shards: 
     { "_id" : "RS1", "host" : "RS1/dbs1d1:27018" } 
     { "_id" : "RS2", "host" : "RS2/dbs1d2:27018" } 
     { "_id" : "RS3", "host" : "RS3/dbs3a:27018" } 
    databases: 
     { "_id" : "admin", "partitioned" : false, "primary" : "config" } 
     { "_id" : "demo", "partitioned" : false, "primary" : "RS1" } 
     { "_id" : "cm_prod", "partitioned" : true, "primary" : "RS1" } 
       cm_prod.profile_daily_stats chunks: 
           RS2  16 
           RS1  16 
         too many chunks to print, use verbose if you want to force print 
       cm_prod.profile_raw_stats chunks: 
           RS2  157 
           RS1  157 
         too many chunks to print, use verbose if you want to force print 
       cm_prod.video_latest_stats chunks: 
           RS1  152 
           RS2  153 
         too many chunks to print, use verbose if you want to force print 
       cm_prod.video_raw_stats chunks: 
           RS1  3257 
           RS2  3257 
         too many chunks to print, use verbose if you want to force print 
      [ ...various unpartitioned DBs snipped...] 

So erscheint die neue RS3 Scherbe in der Liste der Scherben, aber nicht in der Liste der „wie viele Stücke hat jede Scherbe haben“ . Ich hätte erwartet, dass es in dieser Liste mit einer Anzahl von 0 für alle sharded Sammlungen erscheinen würde.

Ist dies erwartet behavord, dass sich aussortieren wird, wenn ich ein bisschen will?

Antwort

3

Es wird anfangen, Blöcke zu haben, ja, in der Tat wird es das Standardziel für jede Chunk-Bewegung für die absehbare Zukunft sein (grundlegende Auswahl ist, von Shard mit den meisten auf den Shard mit den wenigsten Chunks zu verschieben) . Jede primäre Shard-Partition kann nur an einer einzelnen Migration gleichzeitig teilnehmen, so dass einige Chunks zum Verschieben benötigt werden, besonders wenn die anderen beiden ausgelastet sind.

Ich habe Fälle gesehen, in denen Leute den Balancer ausgeschaltet und vergessen haben. Angesichts der Tatsache, dass Ihre anderen 2 Shards ziemlich gut ausbalanciert sind, denke ich nicht, dass dies hier der Fall ist.

Sie können den Status des Balancers durch Verbinden mit den Mongos und dann überprüfen Folgendes tun:

use config; 
db.settings.find({ _id : "balancer" }) 

Stellen Sie sicher, dass "stopped" nicht auf wahr gesetzt ist.

Um zu sehen, was die Sperre hält, und somit zu diesem Zeitpunkt Ausgleich:

use config; 
db.locks.find({ _id : "balancer" }); 

Schließlich, um zu überprüfen, was die Auswuchtmaschine tatsächlich tut, schauen Sie sich die mongos auf dieser Maschine anmelden. Der Balancer gibt Zeilen an das Protokoll mit dem Präfix [Balancer] aus. Sie können auch nach Migrationsnachrichten in den Protokollen der primären mongod-Instanzen in den Protokollen suchen.

EDIT: Dies wurde wahrscheinlich von SERVER-7003 verursacht - ein Fehler in 2.2.0 nach der Veröffentlichung gefunden. Wenn Löschungen im Bereich (Chunk) aus dem Quell-Shard migriert werden, kann dies manchmal zu einer Art Lähmung führen, bei der alle Chunk-Migrationen abgebrochen werden und der Ziel-Shard immer an einer Migration teilnimmt, obwohl dies tatsächlich der Fall ist nicht.

Da dies in 2.2.1 behoben wurde, ist ein Upgrade der empfohlene Weg, um das Problem zu lösen. Allerdings kann es durch Neustarts behoben werden und/oder wenn sich der fehlerhafte Zustand auf dem Ziel-Shard selbst auflöst, wie es in den Kommentaren unten der Fall zu sein scheint.

+0

ich die folgenden Ergebnisse erhalten, die falsch erscheinen (für Lesbarkeit formatiert): 'mongos> use Config geschaltet db config mongos> db.settings.find ({_id: "Balancer"}) mongos> db.locks.find ({_id: "Balancer"}); { "_id": "Balancer", "Prozess": "dbs1d1: 27017: 1343957738: 1804289383," "Zustand": 2, "ts": ObjectId ("50400347f7448e409c964af3"), "when": ISODate ("2012-08-31T00: 20: 23.879Z "), " die": "dbs1d1: 27017: 1343957738: 1804289383: Balancer: 846930886", "Warum": "" Balance Runde tun}' – dstorrs

+0

Argh, verwalten können nicht lesbar zu machen, sorry. Hier eine Zusammenfassung: db.settings.find ({_id: "balancer"}) gibt nichts zurück db.locks.find ({_id: "balancer"}); gibt eine Zeile zurück, die besagt, dass dbs1d1 (ein alternativer Name für dbs1a) besitzt die Sperre Auf dem neuen Shard, db.chunks.find ({shard: "RS3"}). count() gibt 0 zurück. – dstorrs

+0

... Aaand, nachdem es geschrieben wurde, beginnt es jetzt zu erscheinen Sehen Sie dies in den Protokollen der neuen Box (dbs3a), die besagt, dass die Chunk-Bewegungen fehlschlagen (passend zugeschnitten): [Balancer] Bewegter Chunk ns: cm_prod.video_latest_stats bewegt sich (ns: cm_prod.vid eo_latest_stats bei: RS2: RS2/dbs1d2: 27018 ... RS2: RS2/dbs1d2: 27018 -> RS3: RS3/dbs3a: 27018 Donnerstag, 30. August 17:37:06 [Balancer] moveChunk Ergebnis: {cause: {errmsg: "migrieren läuft bereits", ok: 0.0}, errmsg: "moveChunk konnte TO-Shard bei der Datenübertragung nicht aktivieren: migrieren läuft bereits", ok: 0.0} – dstorrs

1

stattdessen db.printShardingStatus(true); wird es Liste von Scherben, Brocken drucken und alle anderen Details