Mongodb Shard Chunk Migration 500 GB dauert 13 Tage - Ist das langsam oder normal?

9

Ich habe Mongodb Shard Cluster, Shard Key ist gehasht. Es hat 2 Shard-Replikatsätze. Jedes Replikatset verfügt über 2 Maschinen.

Ich habe ein Experiment durchgeführt, indem ich zwei weitere Shard-Replikatsätze hinzugefügt habe, und es beginnt sich wieder auszugleichen.

Nach einer Weile stelle ich jedoch fest, dass die Chunk-Migration eher langsam sein soll. Das Verschieben von 1,4 GB Daten dauert 1 Stunde.

Es macht mir Sorgen, es bedeutet, dass ich 13 Tage warten muss, um 500 GB Chunk-Migration abzuschließen!

Ich bin neu in diesem Bereich und ich habe kein göttliches Gefühl, ob es langsam, schnell oder normal ist. Trotzdem überzeugt mich diese Zahl nicht.

Zusätzliche Hinweise zum Experiment: - Verwenden von m3 Medium Aws-Computern - Kein anderer Prozess wird ausgeführt, nur Chunk-Migration - Standard-Mongodb-Sharding-Installation ohne weitere Konfiguration - Shardkey verwendet Hash unter Objekt-ID (_id) - Maximale Chunk-Größe 64 MB

rendybjunior
quelle

Antworten:

10

Update: April 2018

Diese Antwort war zum Zeitpunkt der Frage richtig, aber seitdem haben sich die Dinge weiterentwickelt. Seit Einführung der Version 3.4 wurde Parallelität eingeführt und das Ticket, auf das ich ursprünglich verwiesen habe, wurde geschlossen. Für weitere Informationen gehe ich auf einige Details in dieser neueren Antwort ein . Ich werde den Rest der Antwort unverändert lassen, da sie eine gute Referenz für allgemeine Probleme / Einschränkungen bleibt und für alle Benutzer einer älteren Version gültig ist.

Ursprüngliche Antwort

Wenn Sie interessiert sind, erkläre ich ausführlich, was mit einer Blockmigration im M202 Advanced-Kurs passiert . Nehmen wir im Allgemeinen nur an, dass Migrationen selbst für leere Blöcke nicht sehr schnell sind, da die Verwaltung durchgeführt wird, um sicherzustellen, dass Migrationen in einem aktiven System funktionieren (diese finden immer noch statt, auch wenn nur ein Ausgleich stattfindet).

Darüber hinaus findet jeweils nur eine Migration im gesamten Cluster statt - es gibt keine Parallelität. Trotz der Tatsache, dass Sie zwei "volle" Knoten und zwei "leere" Knoten haben, findet zu jedem Zeitpunkt höchstens eine Migration statt (zwischen dem Shard mit den meisten Chunks und dem Shard mit den geringsten). Wenn Sie also 2 Shards hinzugefügt haben, erhalten Sie nichts an Ausgleichsgeschwindigkeit und erhöhen nur die Anzahl der Chunks, die bewegt werden müssen.

Für die Migrationen selbst sind die Chunks wahrscheinlich ~ 30 MB groß (hängt davon ab, wie Sie Daten aufgefüllt haben, aber im Allgemeinen ist dies Ihr Durchschnitt mit der standardmäßigen maximalen Chunk-Größe). Sie können db.collection.getShardDistribution()nach einigen dieser Informationen suchen und meine Antwort hier finden, um noch mehr Informationen über Ihre Chunks zu erhalten.

Da keine andere Aktivität ausgeführt wird, muss der Ziel-Shard (einer der neu hinzugefügten Shards) für eine Migration ~ 30 MB Daten aus den Quell-Shards (einer der ursprünglichen 2) lesen und die Konfigurationsserver auf aktualisieren Reflektieren Sie den neuen Chunk-Speicherort, sobald er fertig ist. Das Verschieben von 30 MB Daten sollte für ein normales System ohne Last kein großer Engpass sein.

Wenn es langsam ist, gibt es eine Reihe möglicher Gründe, warum dies der Fall ist. Die häufigsten Gründe für ein System, das nicht ausgelastet ist, sind:

  • Quellfestplatten-E / A - Wenn sich die Daten beim Lesen nicht im aktiven Speicher befinden, müssen sie von der Festplatte ausgelagert werden
  • Netzwerk - Wenn Latenz, Ratenbegrenzung, Paketverlust usw. auftreten, kann das Lesen eine Weile dauern
  • Zielfestplatten-E / A - Die Daten und Indizes müssen auf die Festplatte geschrieben werden. Viele Indizes können dies verschlimmern. Auf einem leicht ausgelasteten System ist dies jedoch normalerweise kein Problem
  • Probleme mit Migrationen, die Abbrüche und fehlgeschlagene Migrationen verursachen (Probleme mit Konfigurationsservern, Probleme mit Löschvorgängen auf Primärserien)
  • Replikationsverzögerung - Bei Migrationen zu Replikatsätzen schreiben Sie Bedenken w:2oder w:majoritywerden standardmäßig verwendet und erfordern aktuelle Secondaries, um diese zu erfüllen.

Wenn das System ausgelastet war, dann waren Speicherkonflikte normalerweise auch hier Verdächtige.

Weitere Informationen darüber, wie lange Migrationen dauern, ob sie fehlschlagen usw., finden Sie in den Einträgen in Ihrem config.changelog:

// connect to mongos
use config
db.changelog.find()

Wie Sie gesehen haben und wie ich den Leuten im Allgemeinen sage, wenn ich Training / Ausbildung mache, ist es normalerweise besser, mit 4 zu beginnen, als hochzufahren, wenn Sie wissen, dass Sie 4 Scherben benötigen. Wenn Sie dies tun, müssen Sie sich darüber im Klaren sein, dass das Hinzufügen eines Shards lange dauern kann und sich zunächst eher negativ auf die Ressourcen als auf den Gewinn auswirkt ( eine ausführlichere Beschreibung finden Sie in Teil II meiner Sharding-Fallstricke ).

Informationen zum Verfolgen / Upvoten / Kommentieren der Funktionsanforderung zur Verbesserung der Parallelität von Blockmigrationen finden Sie unter SERVER-4355

Adam C.
quelle
Vielen Dank, dies erklärt den Mechanismus der Chunk-Migration viel mehr als die Mongodb-Dokumentation.
Rendybjunior
Ich werde auf jeden Fall an Ihrem Kurs teilnehmen. :) Was denkst du über die Geschwindigkeit, die ich zuvor erwähnt habe? Ist es normal oder langsam? Ich weiß, dass diese Frage in vielerlei Hinsicht relativ ist. Aber ich bitte um Ihre eigene Meinung
Rendybjunior
Aufgrund Ihrer Beschreibung scheint es etwas langsam zu sein, aber ich müsste mittlere Instanzen vergleichen, um sicherzugehen. Ihre aktuelle Rate ist möglicherweise alles, was sie können, oder Sie haben eines der Probleme, die ich in der Antwort erwähnt habe. Eine Steuerung, die Sie ausprobieren können, ist eine manuelle Blockverschiebung. Schalten Sie den Balancer aus und führen Sie ihn im Wesentlichen selbst aus, um festzustellen, ob Probleme vorliegen und welche Auswirkungen eine Verschiebung auf die Quell- / Zielsysteme hat. Die relevanten Details zu moveChunk finden Sie hier: docs.mongodb.org/manual/reference/method/sh.moveChunk
Adam C
Nur um hinzuzufügen, dass Chunk Mirgation bei MongoDB eine niedrige Priorität hat und selbst bei Hochleistungssystemen einige Zeit in Anspruch nehmen kann, wenn sie beschäftigt sind.
Antonios
@Antonis - Sie sind sich nicht sicher, was Sie unter Priorität verstehen. Eine Blockmigration ist ein Lesevorgang aus dem Quell-Shard (wie bei jedem anderen Lesevorgang) und ein Schreibvorgang auf dem Ziel-Shard (mit dem oben genannten Schreibproblem). Es gibt keine Priorisierung dieser Vorgänge gegen andere. Sie sind auf ausgelasteten Systemen langsam, jedoch nicht aufgrund eines inhärenten Prioritätsunterschieds.
Adam C