Unsere neueste Version von ClusterControl verwandelt einige der schwierigsten MongoDB-Aufgaben in einen Job von nur 15 Sekunden. Neue Funktionen wurden hinzugefügt, um Ihnen mehr Kontrolle über Ihren Cluster zu geben und Topologieänderungen vorzunehmen:
- Konvertieren Sie ein MongoDB-replicaSet in einen fragmentierten MongoDB-Cluster
- Shards hinzufügen und entfernen
- Shard-Router zu einem Sharding-MongoDB-Cluster hinzufügen
- Einen Knoten herunterfahren oder einfrieren
- Neue MongoDB-Berater
Wir werden diese zusätzlichen Funktionen weiter unten ausführlich beschreiben.
Konvertieren Sie ein MongoDB-ReplicaSet in einen Sharded-MongoDB-Cluster
Da die meisten MongoDB-Benutzer mit einem replicaSet zum Speichern ihrer Datenbank beginnen, ist dies der am häufigsten verwendete Clustertyp. Wenn Sie auf Skalierungsprobleme stoßen, können Sie dieses replicaSet skalieren, indem Sie entweder weitere Secondaries hinzufügen oder durch Sharding aufskalieren. Sie können ein vorhandenes replicaSet in einen Sharding-Cluster konvertieren, dies ist jedoch ein langwieriger Prozess, bei dem Sie leicht Fehler machen können. In ClusterControl haben wir diesen Prozess automatisiert, wobei wir automatisch die Konfigurationsserver und Shard-Router hinzufügen und Sharding aktivieren.
Um ein replicaSet in einen Sharding-Cluster umzuwandeln, können Sie es einfach über das Drop-down-Menü Aktionen auslösen:
Dies öffnet einen zweistufigen Dialog darüber, wie man dies in einen Shard umwandelt. Der erste Schritt besteht darin, zu definieren, wo der Configserver und die Shard-Router bereitgestellt werden sollen:
Der zweite Schritt ist, wo die Daten gespeichert werden und welche Konfigurationsdateien für den Configserver und den Shard-Router verwendet werden sollen.
Nachdem der Shard-Migrationsjob abgeschlossen ist, zeigt die Cluster-Übersicht nun Shards anstelle von replicaSet-Instanzen an:
Nach der Konvertierung in einen Sharding-Cluster können neue Shards hinzugefügt werden.
Hinzufügen oder Entfernen von Shards aus einem Sharded MongoDB-Cluster
Fragmente hinzufügen
Da ein MongoDB-Shard technisch gesehen ein Replikatset ist, beinhaltet das Hinzufügen eines neuen Shards auch die Bereitstellung eines neuen Replikatsets. Innerhalb von ClusterControl stellen wir zuerst ein neues replicaSet bereit und fügen es dann dem Sharded-Cluster hinzu.
Über die ClusterControl-Benutzeroberfläche können Sie ganz einfach neue Shards mit einem zweistufigen Assistenten hinzufügen, der über das Dropdown-Menü „Aktionen“ geöffnet wird:
Hier können Sie die Topologie des neuen Shards definieren.
Sobald der neue Shard dem Cluster hinzugefügt wurde, beginnt der MongoDB-Shard-Router damit, ihm neue Chunks zuzuweisen, und der Balancer gleicht automatisch alle Chunks über alle Shards aus.
Scherben entfernen
Das Entfernen von Shards ist etwas schwieriger als das Hinzufügen eines Shards, da dazu die Daten auf die anderen Shards verschoben werden müssen, bevor der Shard selbst entfernt wird. Für alle Daten, die über alle Shards verteilt wurden, ist dies eine Aufgabe, die vom MongoDB-Balancer ausgeführt wird.
Jedoch muss jede nicht geshardete Datenbank/Sammlung, der dieser Shard als primärer Shard zugewiesen wurde, auf einen anderen Shard verschoben und zu einem neuen primären Shard gemacht werden. Für diesen Prozess muss MongoDB wissen, wohin diese nicht fragmentierten Datenbanken/Sammlungen verschoben werden sollen.
In ClusterControl können Sie sie einfach über das Aktions-Dropdown entfernen:
Dadurch können Sie den Shard auswählen, den Sie entfernen möchten, und den Shard, zu dem Sie alle primären Datenbanken migrieren möchten:
Der Job, der den Shard entfernt, führt dann ähnliche Aktionen wie zuvor beschrieben aus:Er verschiebt alle primären Datenbanken auf den angegebenen Shard, aktiviert den Balancer und wartet dann darauf, dass er alle Daten aus dem Shard verschiebt.
Sobald alle Daten entfernt wurden, wird der Shard von der Benutzeroberfläche entfernt.
Hinzufügen zusätzlicher MongoDB-Shard-Router
Sobald Sie beginnen, Ihre Anwendung mit einem MongoDB-Shard-Cluster zu skalieren, werden Sie möglicherweise feststellen, dass Sie zusätzliche Shard-Router benötigen.
Das Hinzufügen zusätzlicher MongoDB-Shard-Router ist mit ClusterControl ein sehr einfacher Vorgang. Öffnen Sie einfach das Dialogfeld „Knoten hinzufügen“ aus der Dropdown-Liste „Aktionen“:
Dadurch wird dem Cluster ein neuer Shard-Router hinzugefügt. Vergessen Sie nicht, den richtigen Standardport (27017) auf dem Router einzustellen.
Stepdown-Server
Falls Sie Wartungsarbeiten am primären Knoten in einem Replikatset durchführen möchten, ist es besser, ihn zuerst auf elegante Weise herunterzufahren, bevor Sie ihn offline schalten. Das Herunterstufen eines primären Hosts bedeutet im Grunde, dass der Host aufhört, ein primärer zu sein, und ein sekundärer wird, und für eine festgelegte Anzahl von Sekunden nicht berechtigt ist, ein primärer Host zu werden. Die Knoten im MongoDB-replicaSet mit Stimmrecht wählen einen neuen primären Knoten, wobei der herabgesetzte primäre Knoten für die festgelegte Anzahl von Sekunden ausgeschlossen wird.
In ClusterControl haben wir die Step-Down-Funktionalität als Aktion auf der Nodes-Seite hinzugefügt. Um zurückzutreten, wählen Sie einfach dies als Aktion aus der Dropdown-Liste aus:
Nachdem Sie die Anzahl der Sekunden für den Rückzug eingestellt und bestätigt haben, tritt der Primäre zurück und ein neuer Primärer wird gewählt.
Einen Knoten einfrieren
Diese Funktionalität ähnelt dem Step-Down-Befehl:Dadurch wird ein bestimmter Knoten für eine festgelegte Anzahl von Sekunden nicht berechtigt, ein primärer Knoten zu werden. Dies bedeutet, dass Sie verhindern können, dass ein oder mehrere sekundäre Knoten zu primären werden, wenn Sie den primären herunterstufen, und auf diese Weise einen bestimmten Knoten zwingen, zum neuen primären Knoten zu werden.
In ClusterControl haben wir die Freeze-Node-Funktionalität als Aktion auf der Nodes-Seite hinzugefügt. Um einen Knoten einzufrieren, wählen Sie einfach dies als Aktion aus der Dropdown-Liste aus:
Nachdem Sie die Anzahl der Sekunden eingestellt und bestätigt haben, ist der Knoten für die festgelegte Anzahl von Sekunden nicht als primär geeignet.
Neue MongoDB-Berater
Berater sind Miniprogramme, die Ratschläge zu bestimmten Datenbankproblemen geben. Wir haben drei neue Berater für MongoDB hinzugefügt. Der erste berechnet das Replikationsfenster, der zweite überwacht das Replikationsfenster und der dritte prüft auf nicht-sharded Datenbanken/Sammlungen.
MongoDB Replication Lag Advisor
Die Replikationsverzögerung ist sehr wichtig, um sie im Auge zu behalten, wenn Sie Lesevorgänge skalieren, indem Sie mehr Sekundäre hinzufügen. MongoDB verwendet diese Secondaries nur, wenn sie nicht zu weit hinterherhinken. Wenn der sekundäre Server eine Replikationsverzögerung aufweist, riskieren Sie, veraltete Daten bereitzustellen, die bereits auf dem primären Server überschrieben wurden.
Um die Replikationsverzögerung zu überprüfen, genügt es, sich mit dem primären Server zu verbinden und diese Daten mit dem Befehl replSetGetStatus abzurufen. Im Gegensatz zu MySQL verfolgt der Primary den Replikationsstatus seiner Secondaries.
Wir haben diese Prüfung in einen Advisor in ClusterControl implementiert, um sicherzustellen, dass Ihre Replikationsverzögerung immer überwacht wird.
MongoDB Replication Window Advisor
Genau wie die Replikationsverzögerung ist das Replikationsfenster eine ebenso wichtige Metrik, die es zu beachten gilt. Der Lag Advisor informiert uns bereits über die Anzahl der Sekunden, die ein sekundärer Knoten hinter dem primären/Master liegt. Da das Oplog in der Größe begrenzt ist, bringt die Slave-Verzögerung die folgenden Risiken mit sich:
- Wenn ein Knoten zu weit hinterherhinkt, kann er möglicherweise nicht mehr aufholen, da sich die zum Aufholen erforderlichen Transaktionen nicht mehr im Oplog des primären Knotens befinden.
- Ein verzögerter sekundärer Knoten wird bei einer MongoDB-Wahl für einen neuen primären Knoten weniger bevorzugt. Wenn alle sekundären Server bei der Replikation hinterherhinken, haben Sie ein Problem und einer mit der geringsten Verzögerung wird zum primären.
- Nachhinkende Sekundärdatenbanken werden vom MongoDB-Treiber beim horizontalen Hochskalieren von Lesevorgängen mit MongoDB weniger bevorzugt, außerdem wird den verbleibenden Sekundärdatenbanken eine höhere Arbeitslast hinzugefügt.
Wenn ein sekundärer Knoten einige Minuten (oder Stunden) hinterherhinkt, wäre es nützlich, einen Berater zu haben, der uns darüber informiert, wie viel Zeit uns bleibt, bevor unsere nächste Transaktion aus dem Oplog gelöscht wird. Der Zeitunterschied zwischen dem ersten und dem letzten Eintrag im Oplog wird als Replikationsfenster bezeichnet. Diese Metrik kann erstellt werden, indem das erste und letzte Element aus dem Oplog abgerufen und die Differenz ihrer Zeitstempel berechnet wird.
In der MongoDB-Shell steht bereits eine Funktion zur Verfügung, die das Replikationsfenster für Sie berechnet. Diese Funktion ist jedoch in die Befehlszeilen-Shell integriert, sodass externe Verbindungen, die die Befehlszeilen-Shell nicht verwenden, diese integrierte Funktion nicht haben. Deshalb haben wir einen Advisor erstellt, der das Replikationsfenster überwacht und Sie warnt, wenn Sie einen voreingestellten Schwellenwert überschreiten.
MongoDB Un-Sharded Databases and Collections Advisor
Nicht fragmentierte Datenbanken und Sammlungen werden vom MongoDB-Shard-Router einem primären Standard-Shard zugewiesen. Dies bedeutet, dass die Datenbank oder Sammlung auf die Größe dieses primären Shards beschränkt ist und, wenn in großen Volumes geschrieben wird, den gesamten verbleibenden Speicherplatz eines Shards verbrauchen könnte. Sobald dies geschieht, wird der Shard offensichtlich nicht mehr funktionieren. Daher ist es wichtig, alle vorhandenen Datenbanken und Sammlungen zu überwachen und die Konfigurationsdatenbank zu scannen, um zu bestätigen, dass sie für das Sharding aktiviert wurden.
Um dies zu verhindern, haben wir eine ungeteilte Datenbank und einen Sammlungsratgeber erstellt. Dieser Ratgeber scannt jede Datenbank und Sammlung und warnt Sie, wenn sie nicht geteilt wurde.
ClusterControl hat die Wartbarkeit von MongoDB verbessert
Wir haben einen großen Schritt gemacht, indem wir alle Verbesserungen zu ClusterControl für MongoDB-replicaSets und Sharding-Cluster hinzugefügt haben. Dies verbessert die Benutzerfreundlichkeit für MongoDB erheblich und ermöglicht es DBAs, Sysops und Entwicklern, ihre Cluster noch besser zu warten!
