Optimieren Sie die Datenmigration in MongoDB: Resharding-Techniken für Geschwindigkeit und Skalierbarkeit

Müssen Sie eine 2-TB-Sammlung teilen und die Daten in weniger als 24 Stunden auf alle Ihre Shards verteilen? Nutzen Sie Resharding, um Ihre Datenmigration zu beschleunigen!

In diesem Beitrag behandeln wir eine Technik namens „Reshard-to-Shard“, die Resharding verwendet, um Daten schnell über die Shards in Ihrem Cluster zu verteilen.

Wir werden Folgendes durchgehen:

1. Überlegungen vor und während der Migration.
2. So initiieren, überwachen und brechen Sie die schnellere Datenmigration ab.

Wenn Sie neu im Sharding sind oder eine Auffrischung darüber wünschen, wie MongoDB horizontale Skalierbarkeit bietet, schauen Sie sich bitte das an MongoDB-Handbuch .

Inhaltsverzeichnis

• Hintergrund
• Was sind die Vorteile von Reshard-to-Shard?
• Wann sollte ich Reshard-to-Shard verwenden?
• Wann sollte ich Reshard-to-Shard nicht verwenden?
• Was sind die Reshard-zu-Shard-Voraussetzungen?
• Übersicht über die Reshard-to-Shard-Technik
• Reshard-to-Shard-Beispiel
• FAQs

Hintergrund

Wenn eine Sammlung zum ersten Mal in einem Cluster mit mehreren Shards aufgeteilt wird, beginnt der Balancer mit der Migration von Daten von dem Shard, der die kürzlich geteilte Sammlung enthält, zu den anderen Shards im Cluster, um die Sammlung gleichmäßig auf die Shards zu verteilen. Wenn der Balancer Daten migriert, kann ein Shard jeweils nur an einer Migration teilnehmen, unabhängig davon, wie viele Sammlungen migriert werden müssen. Das bedeutet, dass in einem 3-Shard-Cluster jeweils nur zwei Shards Daten zwischen ihnen migrieren können. Aufgrund der internen Ausführungsunterschiede gelten für Resharding nicht dieselben Einschränkungen.

Da beim Resharding alle Daten neu geschrieben werden, können Daten parallel über alle Shards im Cluster geschrieben werden, wodurch der Durchsatz erhöht und die Zeit für die Datenmigration über die Shards im Vergleich zu dem, was der Balancer leisten kann, erheblich verkürzt wird. Resharding erstellt eine neue Sammlung mit einem neuen Shard-Schlüssel im Hintergrund auf jedem der Shards, während Ihre vorhandene Sammlung für die Nutzung durch Ihre Anwendung verfügbar bleibt. Sobald alle Dokumente in die neue Sammlung geklont sind, erfolgt die Umstellung. Die vorhandene Sammlung mit dem alten Shard-Schlüssel wird zugunsten der neuen Sammlung gelöscht, die durch den Resharding-Vorgang erstellt wurde.

Was sind die Vorteile von Reshard-to-Shard?

Erstens ist es viel schneller! Durch die Nutzung von Resharding konnte ein Kunde seine 3,5-TB-Sammlung in 22,5 Stunden fragmentieren und auf 4 Shards verteilen. Derselbe Vorgang hätte 30 Tage gedauert, wenn er der Standardmethode des Balancers für Chunk-Migrationen überlassen worden wäre.

Zweitens hat es nur minimale Auswirkungen auf Ihre Arbeitsbelastung! Nachdem der Balancer Daten migriert hat, muss er einen sogenannten Bereinigungsvorgang durchführen Bereichslöschung auf dem Shard, der die Daten gespendet hat, da nur ein Shard jedes spezifische Dokument besitzen kann. Das Löschen von Bereichen ist ein I/O-intensiver Vorgang, der sich auf die Leistung Ihres Clusters auswirken kann. Beim Resharding muss kein Bereich gelöscht werden, da die alte Sammlung gelöscht wird, nachdem mit dem neuen Shard-Schlüssel auf die neue Sammlung umgeschaltet wird.

Drittens gewinnen Sie automatisch Ihren Speicherplatz zurück! Durch das Löschen der alten Sammlung wird Speicherplatz frei, der von jeder Sammlung verwendet werden kann, ohne dass ein Vorgang wie ausgeführt werden muss kompakt . Dies bedeutet, dass Sie den Speicher nach der Operation bei Bedarf schneller und einfacher verkleinern können.

Beispielsweise verbrauchte ein Kunde fast 2,8 TB auf shard0, bevor der Resharding-Vorgang seiner größten Sammlung abgeschlossen war.

Nach Abschluss des Reshardings wurden sofort 1,9 TB Speicherplatz zurückgegeben! Der Speicherverbrauch stieg von 2,7 TB auf 873 GB.

Wann sollte ich Reshard-to-Shard verwenden?

Antwort: Wenn Sie zunächst eine Sammlung beliebiger Größe auf eine beliebige Anzahl von Shards aufteilen.

Es gibt einige Szenarien, in denen der Ausgleich schneller erfolgen kann (z. B. weniger als 100 GB), Sie müssen jedoch dennoch die Bereichslöschung und die Wiederherstellung des Speichers über Komprimierung oder Erstsynchronisierung in Betracht ziehen. Wenn Sie über die nötige Kapazität verfügen, empfehlen wir daher Reshard-to-Shard, unabhängig davon, wie groß die Sammlung ist, die Sie teilen möchten.

Wann sollte ich Reshard-to-Shard nicht verwenden?

Sie sollten die Reshard-zu-Shard-Taktik nicht verwenden, wenn:

• Ihre Anwendung kann eine Blockierung von Schreibvorgängen für zwei Sekunden nicht tolerieren, um die Umstellung auf die neu erstellte Sammlung zu ermöglichen.

  • Die Dauer, für die Schreibvorgänge für die Sammlung, die erneut geshardt wird, blockiert werden können, beträgt standardmäßig zwei Sekunden. Es gibt einen konfigurierbaren Parameter, der die Blockierungsdauer ändern kann.

    
    

• Ihre Sammlung ist eine Zeitreihensammlung
  • Wenn Sie versuchen, eine Zeitreihensammlung neu zu formatieren, erhalten Sie eine Fehlermeldung, die besagt, dass die Neuverteilung einer Zeitseriensammlung nicht unterstützt wird.

Verwenden Sie für die oben aufgeführten Szenarien die herkömmliche Methode, eine Sammlung zu fragmentieren und den Balancer die Daten migrieren zu lassen.

Was sind die Reshard-zu-Shard-Voraussetzungen?

1. Ein MongoDB- Cluster, auf dem MongoDB 5.0 oder höher ausgeführt wird

   1. Wenn Sie MongoDB 5.0 oder 6.0 ausführen, stellen Sie sicher, dass Ihr Cluster eine Patch-Version größer als 5.0.14 oder 6.0.3 ausführt

2. Sie müssen einen geeigneten Shard-Schlüssel für Ihre Sammlung auswählen.

3. Erstellen Sie die erforderlichen Indizes, um sowohl den temporären Shard-Schlüssel als auch den gewünschten Shard-Schlüssel zu unterstützen.

4. Da Sie außerdem Resharding verwenden werden, um die Geschwindigkeit der Datenmigration zu beschleunigen, machen Sie sich bitte mit dem vertraut Resharding-Anforderungen und -Einschränkungen .

Um einen Resharding-Vorgang erfolgreich auszuführen, sollte Ihr Cluster über Folgendes verfügen:

• 2,2-fache Sammlungsgröße pro Shard, die auf jedem Shard verfügbar ist.
  • Wenn Sie beispielsweise eine 1-TB-Sammlung auf 4 Shards aufteilen, beträgt die Shard-Sammlungsgröße 250 GB pro Shard, wenn sie auf 4 Shards verteilt wird. Auf jedem Shard sollten mindestens 550 GB Speicherplatz verfügbar sein.
• I/O-Kapazität unter 50 %
• CPU-Auslastung unter 80 %

Kunden, die Atlas verwenden und deren Cluster nicht die Speicher-, I/O- und CPU-Anforderungen für die Durchführung des Reshardings erfüllt, können dies problemlos vorübergehend tun Skalieren Sie ihren Cluster und/oder Speicher anpassen um die Ressourcen ihres Clusters zu erhöhen, um einen erfolgreichen Resharding-Vorgang zu ermöglichen. Sobald der Vorgang abgeschlossen ist, können sie wieder in den Normalzustand zurückkehren.

Übersicht über die Reshard-to-Shard-Technik

Es gibt zwei sehr einfache Schritte, um einen Reshard-zu-Shard-Vorgang auszuführen:

1. Shard in einen temporären Shard-Schlüssel umwandeln
2. Resharden Sie in Ihren gewünschten Shard-Schlüssel um

Warum sollte ich zuerst einen Sharding-Schlüssel in einen temporären Shard-Schlüssel umwandeln, und würde das meiner Anwendung nicht schaden?

Lass es uns erklären!

Schritt eins: Shard mit einem temporären Shard-Schlüssel

Derzeit unterstützt das Resharding kein Resharding in denselben Shard-Schlüssel (es wird als „No-Op“ erfolgreich sein, da Sie sich bereits im gewünschten Zustand befinden). Um diese Einschränkung zu umgehen, erfordert die Reshard-to-Shard-Technik das absichtliche Sharding in einen temporären Shard-Schlüssel, der sich vom gewünschten Shard-Schlüssel unterscheidet. Da MongoDB sowohl Range Sharding als auch Hashed Sharding unterstützt, kann der temporäre Shard-Schlüssel geringfügig vom gewünschten Shard-Schlüssel abweichen, den Sie für Ihre Sammlung ausgewählt haben.

Der temporäre Shard-Schlüssel sollte eine andere Partitionierungsstrategie nur für eines Ihrer Shard-Schlüsselfelder auswählen. Aufgrund von Einschränkungen für bestimmte Abfragen wie updateOne(), updateMany(), deleteOne() usw., die erfordern, dass die Abfrage den Shard-Schlüssel enthält, verwenden Sie eine andere Partitionierungsstrategie. MongoDB verwendet Partitionierungsstrategien nur , um zu bestimmen, wie Ihre Daten auf die Shards in Ihrem Cluster verteilt werden. Die Werte im Dokument werden dadurch nicht geändert. Das bedeutet, dass Ihre Anwendung eine updateOne oder eine andere Abfrage verwenden kann, die den Shard-Schlüssel mit beiden Partitionierungsstrategien erfordert.

Wenn der gewünschte Shard-Schlüssel, den Sie für Ihre Sammlung ausgewählt haben, beispielsweise folgender ist:

 {"_id": "hashed"}

Der temporäre Shard-Schlüssel, den Sie zunächst für Ihre Sammlung verwenden, sollte sein:

 {"_id": 1}

Bei zusammengesetzten Shard-Schlüsseln können Sie das Präfix des gewünschten Shard-Schlüssels für den temporären Shard-Schlüssel verwenden. Wenn der gewünschte Shard-Schlüssel, den Sie für Ihre Sammlung ausgewählt haben, beispielsweise folgender ist:

 { launch_vehicle: 1, payload: 1}

Ihr temporärer Shard-Schlüssel sollte sein:

 { launch_vehicle: 1}

Die Reshard-zu-Shard-Taktik erfordert ein fast sofortiges Resharding in den Shard-Schlüssel, den Sie langfristig verwenden werden, nachdem das erste Sharding der Sammlung mit dem temporären Shard-Schlüssel abgeschlossen ist. Dadurch bleiben über 99 % der Daten auf einem Shard, während der Resharding-Vorgang ausgeführt wird, wodurch die Auswirkungen von Broadcast-Abfragen erheblich reduziert werden.

Da Sie beide Indizes für Ihren temporären und gewünschten Shard-Schlüssel erstellt haben, während der Resharding-Vorgang ausgeführt wird, sind Abfragen, die Ihren gewünschten Shard-Schlüssel verwenden, performant, da sie den Index für den gewünschten Shard-Schlüssel nutzen können, während Ihre Sammlung vorübergehend partitioniert wird durch Ihren temporären Shard-Schlüssel.

Schritt zwei: Resharden Sie in den gewünschten Shard-Schlüssel um

Der zweite Schritt besteht darin, einen normalen Resharding-Vorgang auszuführen, mit der Ausnahme, dass Sie einen Nebeneffekt der Funktionsweise des Reshardings zu Ihrem Vorteil nutzen.

Resharding besteht aus vier Hauptphasen:

• Initialisierung – die Sammlung, die einem Resharding unterzogen wird, wird abgetastet und eine neue Datenverteilung basierend auf dem neuen Shard-Schlüssel bestimmt.

  
  

• Index – Der Resharding-Vorgang erstellt eine neue leere temporäre Shard-Sammlung auf allen Shards basierend auf dem neuen Shard-Schlüssel und erstellt die Indizes, einschließlich der Nicht-Shard-Schlüssel-Indizes, die die vorhandene Sammlung unterstützen.

  
  

• Klonen, Aufholen und Anwenden – Dokumente werden entsprechend dem neuen Shard-Schlüssel auf die Shards geklont, und alle Änderungen an Dokumenten, während der Resharding-Vorgang ausgeführt wurde, werden angewendet.

  
  

• Commit – Die temporäre Sammlung wird umbenannt und ersetzt die Sammlung, die neu eingeteilt wird, und die jetzt alte Sammlung wird gelöscht.

Nachdem Sie die oben genannten Phasen durchgesehen haben, können Sie sehen, wie Sie auf einmal von einer schnellen Datenverschiebung, einer Shard-Sammlung, die nach Abschluss des Vorgangs gleichmäßig auf Ihre Shards verteilt wird, und der Freigabe von Speicherplatz profitieren.

Sobald der Resharding-Vorgang abgeschlossen ist, können Sie Bereinigungsvorgänge durchführen, z. B. das Löschen des temporären Shard-Schlüsselindex und das Verkleinern Ihres Clusters und/oder Ihres Speichers, um Ihren stabilen Anforderungen gerecht zu werden.

Reshard-to-Shard-Beispiel

Nehmen wir an, Sie arbeiten an einer Anwendung, die Verkehrsflugzeuge verfolgt, damit Kunden benachrichtigt werden können, wenn eine Verspätung ihres Fluges wahrscheinlich ist. Sie haben die Abfragemuster Ihrer Anwendung untersucht und überprüft, welche Attribute zu einem guten Shard-Schlüssel beitragen.

Der Shard-Schlüssel, den Sie für Ihre Sammlung ausgewählt haben, ist:

 { airline: 1, flight_number: 1, date: "hashed" }

Sobald der Shard-Schlüssel bestimmt ist, können Sie damit beginnen, die Voraussetzungen für die Ausführung eines Reshard-zu-Shard-Vorgangs abzuhaken. Zuerst generieren Sie Ihren temporären Shard-Schlüssel. Wie bereits erwähnt, soll Ihr temporärer Shard-Schlüssel eine leicht modifizierte Version des gewünschten Shard-Schlüssels sein.

Der von Ihnen ausgewählte temporäre Shard-Schlüssel lautet also:

 { airline: 1, flight_number: 1 }

Als Nächstes erstellen Sie die Indizes, um sowohl den temporären als auch den endgültigen Shard-Schlüssel zu unterstützen.

Indizes können mit der Mongo-Shell über db.collection.createIndex() oder db.collection.createIndexes() erstellt werden.

Da der gewünschte Shard-Schlüssel ein zusammengesetzter Shard-Schlüssel ist, müssen Sie nur einen Index über db.collection.createIndexes() erstellen:

 db.flight_tracker.createIndex( { "airline": 1, "flight_number": 1, date: "hashed" } )

Die Indexerstellungen können mit der Mongo-Shell über den folgenden Befehl überwacht werden:

 db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] })

Wenn Ihr MongoDB-Cluster auf Atlas bereitgestellt ist, können Sie die Atlas-Benutzeroberfläche verwenden, um ganz einfach die verfügbaren Metriken zu überprüfen, die Sie darüber informieren, dass Ihr Cluster über genügend freien Speicher sowie CPU- und E/A-Spielraum für die Durchführung eines Resharding-Vorgangs verfügt.

Wenn nicht genügend Speicherplatz oder E/A-Spielraum vorhanden ist, können Sie den Speicher skalieren. Bei mangelndem CPU-Spielraum können Sie den Cluster skalieren. Die Skalierung von Speicher und Cluster erfolgt einfach über die Atlas-Benutzeroberfläche.

Der Zugriff auf die Clusterkonfiguration ist einfach und kann über den Übersichtsbildschirm Ihrer Gruppe erfolgen, auf dem alle bereitgestellten Cluster für die Gruppe angezeigt werden.

Wenn alle Voraussetzungen erfüllt sind, können Sie mit dem ersten Teil des Reshard-to-Shard-Prozesses beginnen – dem Sharding der Sammlung mit dem temporären Shard-Schlüssel.

Anschließend können Sie die Mongo-Shell und den Befehl sh.shardCollection() verwenden, um die Sammlung zu teilen:

 sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1 })

sh.shardCollection() gibt nach Abschluss ein Dokument zurück. Das Feld ok hat den Wert 1, wenn der Vorgang erfolgreich war.

 { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) }

Warten Sie nach dem Shardieren der Sammlung, bis ein Block auf jeden Shard im Cluster migriert wurde. Sie können über sh.status() in der Mongo-Shell überprüfen, ob jeder Shard einen Block hat:

 sh.status()

Um Ihre Sammlung in den gewünschten Shard-Schlüssel umzuwandeln, verwenden Sie sh.reshardCollection() in der Mongo-Shell:

 sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" })

Wenn Sie den Befehl sh.status() in der Mongo-Shell ausführen, wird in der Ausgabe eine neue Sammlung angezeigt, deren Name im Format <db_name>.system.resharding.<UUID> lautet. Dies ist die Sammlung, die beim Resharding erstellt und die Daten entsprechend Ihrem gewünschten Shard-Schlüssel verteilt

Um den Status des Resharding-Vorgangs für die Flight_tracker-Sammlung zu überwachen, können Sie den folgenden Befehl verwenden

 db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "main.flight_tracker" } } ])

Die Ausgabe des Befehls informiert Sie über die Phase, in der der Resharding-Vorgang gerade ausgeführt wird, und über die geschätzte Zeit bis zum Abschluss über das Feld „RemainingOperationTimeschätzungSecs“. Bitte beachten Sie, dass die geschätzte Zeit bis zum Abschluss des Resharings pessimistisch ist und Resharding-Vorgänge deutlich weniger Zeit in Anspruch nehmen als angegeben!

Der Resharding-Vorgang sollte fast abgeschlossen sein, wenn die Datengröße jedes Shards um die Größe der neu zu teilenden Sammlung geteilt durch die Anzahl der Shards im Cluster zugenommen hat. Wenn beispielsweise eine 1-TB-Sammlung auf 4 Shards neu verteilt wird, sollte der Resharding-Vorgang abgeschlossen sein, wenn jeder Shard 250 GB geschrieben hat (ohne Berücksichtigung anderer Daten, die auf dem Shard eingefügt, aktualisiert oder gelöscht werden).

Wenn Ihr Cluster auf Atlas bereitgestellt ist, können Sie den Fortschritt des Resharding-Vorgangs auch über die Atlas-Benutzeroberfläche überwachen, indem Sie die Registerkarte „Metriken“ des Clusters verwenden.

• Für Atlas-Cluster, auf denen MongoDB 6.0 und höher ausgeführt wird, können Sie die Option zur Anzeige der Shard-Datengröße verwenden und dann eine Sammlung mit der Syntax <db_name>.system.resharding.<UUID> auswählen. Diese Ansicht isoliert die temporäre Sammlung und zeigt nur das Datengrößenwachstum der neuen Sammlung an.

  
  

• Für Atlas-Cluster, auf denen MongoDB 5.0 ausgeführt wird, können Sie die Option zur Anzeige der logischen Datenbankgröße verwenden. Diese Ansicht ermöglicht keine Isolierung auf Sammlungsebene.

  
  

Während das Resharding ausgeführt wird, sollten Sie in erster Linie die drei Metriken des Clusters überwachen:

• Verfügbarer Speicher – Die Nutzung des gesamten verfügbaren Speichers kann zu Cluster-Instabilität führen
• CPU-Auslastung – Eine hohe CPU-Auslastung kann zu einer verminderten Clusterleistung führen
• E/A-Nutzung – Eine über Ihre Kapazität hinausgehende E/A-Nutzung kann zu einer verminderten Clusterleistung führen

Wenn Sie jemals befürchten, dass sich das Resharding negativ auf Ihren Cluster auswirkt, können Sie den Resharding-Vorgang mit dem folgenden Befehl sofort abbrechen, bevor er den Commit-Teil des Prozesses erreicht:

 sh.abortReshardCollection("main.flight_tracker")

Wenn der Resharding-Vorgang abgeschlossen ist, wird an den aufrufenden Client zurückgegeben, ob der Vorgang erfolgreich war oder nicht.

Da es sich beim Resharding um einen Vorgang mit langer Laufzeit handelt und Sie möglicherweise die Mongo-Shell-Sitzung geschlossen haben, können Sie mithilfe der Resharding-Überwachungsaggregation überprüfen, ob der Sharding-Vorgang noch ausgeführt wird, wenn Sie Details wünschen, oder __ sh.status() __, um zu sehen, ob der Sharding-Vorgang vorübergehend ist Die Sammlung ist immer noch in der Ausgabe vorhanden. Wenn die Resharding-Aggregation nichts zurückgibt oder Sie in der Ausgabe von sh.status() keine temporäre Sammlung mehr sehen, ist der Resharding-Vorgang beendet.

Sie können db.collection.getShardDistribution verwenden, um festzustellen, ob der Vorgang erfolgreich war:

 db.flight_tracker.getShardDistribution()

Wenn das Resharding erfolgreich abgeschlossen wurde, sollten Sie eine Ausgabe sehen, in der die Verteilung über alle Shards hinweg gleich ist.

• Bei MongoDB 6.0 und höher wird die Gleichmäßigkeit durch die Datengröße pro Shard bestimmt, sodass Sie in der Ausgabe von db.collection.getShardDistribution auf jedem Shard eine nahezu gleiche Datenmenge sehen sollten.

  
  

• Bei MongoDB 5.0 wird die Gleichmäßigkeit durch die Anzahl der Chunks pro Shard bestimmt. Daher sollten Sie in der Ausgabe von db.collection.getShardDistribution auf jedem Shard die gleiche Anzahl von Chunks sehen.

Wenn Ihr Cluster auf Atlas bereitgestellt ist, können Sie die Atlas-Benutzeroberfläche über die Registerkarte „Metriken“ verwenden, um festzustellen, ob der Resharding-Vorgang erfolgreich ist.

• Für Atlas-Cluster, auf denen MongoDB 6.0 und höher ausgeführt wird, können Sie die Option zur Anzeige der Shard-Datengröße verwenden und dann Ihre Sammlung auswählen, die einem Resharding unterzogen wurde. Es sollte die gleiche Datenmenge pro angezeigtem Shard angezeigt werden.

  
  

• Für Atlas-Cluster, auf denen MongoDB 5.0 ausgeführt wird, können Sie die Anzeigeoption „Chunks“ verwenden und dann Ihre Sammlung auswählen, die einem Resharding unterzogen wurde. Auf allen Shards in Ihrem Cluster sollte eine nahezu gleiche Anzahl von Blöcken angezeigt werden.

  
  

Sowohl für die Shard-Datengröße als auch für die Anzahl der Blöcke zeigt die Atlas-Benutzeroberfläche einen starken Anstieg der relevanten Metrik an, da das Resharding vorübergehend mit dem Sammlungsnamenformat <db_name>.system.resharding.<UUID> durchgeführt wird, bevor es umbenannt und das alte gelöscht wird Sammlung mit dem alten Shard-Schlüssel.

Wenn das erneute Sharding abgebrochen wird, zeigt die Ausgabe von db.collection.getShardDistribution wahrscheinlich die meisten Daten auf dem Shard an, auf dem die Sammlung ursprünglich fragmentiert wurde. Abbrüche beim Resharding sind selten und wahrscheinlich, weil das Resharding die Umstellung der Sammlung nicht in 2 Sekunden oder weniger durchführen konnte.

Wenn dies der Fall ist, empfehlen wir, den Start des Reshardings so zu planen, dass versucht wird, in einem Zeitraum mit geringerem Datenverkehr für Ihren Cluster ein Commit durchzuführen.

Sobald der Resharding-Vorgang abgeschlossen ist, können Sie Bereinigungsvorgänge durchführen, z. B. das Löschen des temporären Shard-Schlüsselindex und das Verkleinern Ihres Clusters und/oder Ihres Speichers, um Ihren stabilen Anforderungen gerecht zu werden.

FAQs

1. Wie lange dauert der Austausch von Reshard zu Shard?

   
   

   • Dies hängt von der Größe Ihrer Sammlung, der Anzahl und Größe der Indizes für Ihre Sammlung und der Anzahl der Shards in Ihrem Cluster ab. Wir sind jedoch zuversichtlich, dass Sie eine 4-TB-Sammlung mit 10 Indizes auf 4 Shards in 48 Jahren neu aufteilen können Stunden oder weniger. Es würde 30 Tage oder länger dauern, die Migrationen dem Balancer zu überlassen.

     
     

2. Warum ist das Resharding schneller, als den Balancer die Daten migrieren zu lassen?

   
   

   • Die internen Mechanismen, wie Balancer und Resharding Daten migrieren, sind unterschiedlich. Beim Resharding werden Dokumente in einer anderen Reihenfolge gelesen als bei der Chunk-Migration. Da das Resharding mit dem Löschen der alten Sammlung endet, muss nicht auf die Bereichslöschung gewartet werden, um den Speicherplatz freizugeben.

     
     

3. Ich möchte Reshard-to-Shard für eine Sammlung verwenden, die einer Eindeutigkeitsbeschränkung unterliegt und Hash-Indizes die Erzwingung der Eindeutigkeit nicht unterstützen.

   
   

   • Wenn für Ihre Sammlung eine Eindeutigkeitsbeschränkung gilt, können Sie Reshard-to-Shard verwenden, müssen jedoch einen anderen Ansatz wählen. Indem Sie Ihrem temporären Shard-Schlüssel ein zusätzliches Feld hinzufügen, anstatt die Partitionierungsstrategie zu ändern, schalten Sie die Möglichkeit frei, in den gewünschten Shard-Schlüssel umzuwandeln. Wenn Ihr gewünschter Shard-Schlüssel beispielsweise wie folgt lautet:

     
     

      { launch_vehicle: 1, payload: 1}

     
     

   • Ihr temporärer Shard-Schlüssel wäre:

      { launch_vehicle: 1, payload: 1, launch_pad: 1}

     
     

   • Bitte beachten Sie die Einschränkungen für Abfragen (z. B. updateOne(), updateMany(), deleteOne()), die erfordern, dass die Abfrage den vollständigen Shard-Schlüssel enthält. Ihre Anwendung muss den temporären Shard-Schlüssel in allen Szenarios enthalten, in denen eine Abfrage den vollständigen Shard-Schlüssel erfordert, um erfolgreich ausgeführt zu werden, bis der Resharding-Vorgang abgeschlossen ist.

   
   

4. Wie überwache ich einen laufenden Resharding-Vorgang?

   • Führen Sie den folgenden Befehl aus:

      db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ])

   
   

5. Wie stoppe ich einen laufenden Resharding-Vorgang?

   
   

   • Führen Sie den folgenden Befehl aus, der den Resharding-Vorgang sofort abbricht:

      sh.abortReshardCollection("<database>.<collection>")

   
   

6. Ich mache mir Sorgen, dass das Resharding die Leistung meines Clusters beeinträchtigen könnte.

   
   

   • Wenn Sie die zuvor beschriebenen Resharding-Anforderungen erfüllen, sollte sich der Vorgang nicht auf die Leistung Ihres Clusters auswirken. Wenn Ihr Cluster jedoch auf Atlas bereitgestellt wird, können Sie Ihren Cluster vorübergehend hochskalieren, während Sie einen Reshard-zu-Shard-Vorgang ausführen, und den Cluster nach Abschluss des Vorgangs wieder herunterskalieren.

     
     

7. Welche Metriken meines Clusters sollte ich während der Ausführung des Resharding-Vorgangs überwachen?

   
   

   • Verfügbarer Speicherplatz – wenn auf einem Ihrer Shards weniger als 100 GB Speicherplatz verfügbar sind, sollten Sie das Resharding abbrechen

   • CPU-Auslastung – Wenn Ihr Cluster alle verfügbaren Rechenressourcen verbraucht, kann es zu Ressourcenkonflikten kommen und Sie sollten das Resharding abbrechen

   • E/A-Verbrauch – Wenn Ihr Cluster alle verfügbaren IOPS verbraucht, kann es zu Ressourcenkonflikten kommen und Sie sollten das Resharding abbrechen.

     
     

8. Die temporäre Sammlung ist scheinbar gleichmäßig auf alle meine Shards verteilt. Warum ist das Resharding nicht abgeschlossen?

   
   

   • Bevor das Resharding mit dem gewünschten Shard-Schlüssel auf die Sammlung übertragen werden kann, muss dies geschehen aufholen mit allen Schreibvorgängen, die seit der Initiierung des Reshardings stattgefunden haben. Wenn Ihre Schreibarbeitsbelastung hoch ist, kann es längere Zeit dauern, bis die Aufholphase abgeschlossen ist.