MongoDB
 sql >> Datenbank >  >> NoSQL >> MongoDB

Eine Anleitung zum Konfigurieren eines Load Balancer in einem MongoDB Sharded Cluster

Für jede Datenbank ist der Lastausgleich aller Anfragen von Clients ein wichtiger und grundlegender Mechanismus, um die Skalierbarkeit sicherzustellen. Eine geeignete Lastausgleichslösung verteilt alle Clientanforderungen gleichmäßig auf alle Datenbankressourcen. Wenn der Datenbank-Cluster nicht mit einer geeigneten Lastausgleichslösung geschützt ist, kann Ihre Datenbank die erhöhte Verkehrslast nicht bewältigen.

Glücklicherweise bietet MongoDB integrierte Unterstützung für den Lastenausgleich des hohen Datenverkehrs, indem horizontale Skalierung durch Sharding unterstützt wird. Per Sharding können Sie die Daten Ihrer Sammlungen auf mehrere Server verteilen. Sie können Ihrem Cluster auch neue Server/Maschinen hinzufügen, um den erhöhten Datenverkehr in der Datenbank zu bewältigen. Sie können dieser Anleitung folgen, um Ihren MongoDB-Replikat-Cluster in einen Sharding-Cluster umzuwandeln.

In diesem Artikel lernen wir das Verhalten des Balancer-Prozesses kennen, der in den Sharding-Clustern von MongoDB ausgeführt wird, und wie sein Verhalten geändert werden kann. Der MongoDB-Balancer-Prozess kümmert sich um die gleichmäßige Verteilung Ihrer Sammlungen auf die Shards. Wenn beispielsweise ein Shard Ihres Clusters zu viele Chunks Ihrer Shard-Sammlung enthält, kann dieser bestimmte Shard im Vergleich zu anderen Shards mehr Datenverkehr erhalten. Daher gleicht der Balancer-Prozess die Chunks der Sammlungen ordnungsgemäß über die Shards aus. In den meisten MongoDB-Bereitstellungen reichen die Standardkonfigurationen des Balancer-Prozesses für den normalen Betrieb aus. In einigen Situationen möchten Datenbankadministratoren jedoch möglicherweise das Standardverhalten dieses Prozesses ändern. Wenn Sie das Standardverhalten des Balancer-Prozesses für Anforderungen auf Anwendungsebene oder betriebliche Anforderungen ändern möchten, können Sie dieser Anleitung folgen.

Lassen Sie uns mit einigen grundlegenden Befehlen beginnen, um einige Informationen über den Zustand und Status des Balancer-Prozesses zu erhalten.

Balancer-Statusstatus

Dieser Befehl prüft, ob der Balancer aktiviert ist oder ausgeführt werden darf oder nicht. Wenn der Balancer-Prozess nicht läuft, gibt dieser Befehl „false“ zurück. Dabei wird nicht überprüft, ob der Balancer-Prozess läuft oder nicht.

sh.getBalancerState()

Balancer-Prozess aktivieren

Wenn der Balancer standardmäßig nicht aktiviert ist, können Sie ihn aktivieren, indem Sie den folgenden Befehl ausführen. Dieser Befehl startet den Balancer-Prozess nicht, aber er aktiviert den Prozess und stellt sicher, dass der Chunk-Ausgleich nicht blockiert wird, wenn der Balancer-Prozess das nächste Mal ausgeführt wird.

sh.enableBalancing(<collection_name/namespace>)

Balancer-Prozess deaktivieren

Der Balancer-Prozess wird standardmäßig jederzeit ausgeführt. Wenn Sie also den Balancer-Prozess für einen bestimmten Zeitraum deaktivieren möchten, können Sie den folgenden Befehl verwenden. Ein ideales Szenario für die Verwendung dieses Befehls ist, wenn Sie eine Sicherungskopie Ihrer Datenbank erstellen.

sh.stopBalancer()

Stellen Sie sicher, dass der Balancer-Prozess gestoppt ist, bevor Sie die Sicherung erstellen. Wenn der Prozess während der Erstellung der Datenbanksicherung aktiviert ist, erhalten Sie möglicherweise eine inkonsistente Replik Ihrer Datenbank. Dies kann passieren, wenn der Balancer-Prozess einige Chunks über die Shards zum Lastenausgleich während des Backup-Prozesses verschiebt.

Sie können das Balancing auch für einige spezifische Sammlungen deaktivieren, indem Sie den vollständigen Namensraum einer Sammlung als Parameter mit dem folgenden Befehl angeben.

sh.disableBalancing("<db_name>.<collection_name>")

Ausgleichsstatus läuft

Dieser Befehl prüft, ob der Balancer-Prozess läuft oder nicht. Es prüft auch, ob es die Sharding-Blöcke aktiv verwaltet oder nicht. Gibt „true“ zurück, wenn der Prozess läuft, ansonsten „false“.

sh.isBalancerRunning()

Standard-Chunk-Größenkonfigurationen

Standardmäßig beträgt die Blockgröße in jedem MongoDB-Shard-Cluster 64 MB. Für die meisten Szenarien ist dies gut genug, um die fragmentierten Chunks zu migrieren oder aufzuteilen. Manchmal umfasst der normale Migrationsprozess jedoch mehr E/A-Operationen, als Ihre Hardware verarbeiten kann. In solchen Situationen möchten Sie vielleicht die Größe der Chunks reduzieren. Sie können dies tun, indem Sie die folgenden Befehle ausführen.

use config

db.settings.save( { _id:"chunksize", value: <sizeInMB> } )

Wenn Sie die standardmäßige Chunk-Größe im Sharding-Cluster ändern, beachten Sie die folgenden Dinge

  • Sie können die Blockgröße nur zwischen 1 und 1024 MB angeben
  • Automatisches Aufteilen erfolgt nur beim Einfügen oder Aktualisieren
  • Kleinere Chunk-Größen führen zu mehr Zeit während des Aufteilungsprozesses.

Planen Sie den Ausgleich für eine bestimmte Zeit

Wenn Ihre Datenbank sehr groß ist, können Ausgleichs- oder Migrationsprozesse die Gesamtleistung Ihrer Datenbank beeinträchtigen. Daher ist es ratsam, den Ausgleichsprozess in einem bestimmten Zeitfenster zu planen, in dem die Belastung der Datenbank sehr gering ist. Sie können die folgenden Befehle verwenden, um das Zeitfenster für die Ausführung des Balancer-Prozesses festzulegen.

use config

db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } }, true )

Beispiel

Der folgende Befehl legt das Zeitfenster von 1:00 Uhr bis 5:00 Uhr fest, in dem der Ausgleichsprozess ausgeführt wird.

db.settings.update({ _id : "balancer" }, { $set : { activeWindow : { start : "01:00", stop : "05:00" } } }, true )

Stellen Sie sicher, dass der angegebene Zeitrahmen für einen vollständigen Ausgleichsprozess ausreicht.

Sie können auch jedes vorhandene Zeitfenster für den Ausgleichsprozess entfernen, indem Sie den folgenden Befehl ausführen.

db.settings.update({ _id : "balancer" }, { $unset : { activeWindow : true } })

Abgesehen von den obigen Befehlen können Sie auch das Replikationsverhalten ändern, während Sie den Chunk-Migrationsprozess durchführen, indem Sie den Parameter _secondaryThrottle verwenden. Außerdem können Sie die Eigenschaft _waitForDelete mit dem Befehl moveChunk verwenden, um den Ausgleichsprozess anzuweisen, auf die Löschphase der aktuellen Migration zu warten, bevor er mit der neuen Chunk-Migrationsphase beginnt.

Fazit

Hoffentlich ist dies alles, was Sie brauchen, während Sie das Standardverhalten des MongoDB-Balancer-Prozesses ändern. Balancing ist ein sehr wichtiger Aspekt jedes Sharding-Clusters von MongoDB. Wenn Sie also den Ausgleichsprozess im Detail kennen, wird es sehr einfach, das Standardverhalten des Ausgleichsprozesses entsprechend Ihren Anforderungen und Anwendungsfällen zu ändern.