Überlegungen zur Verwaltung von MongoDB

Nachfolgend finden Sie einen Auszug aus unserem Whitepaper „MongoDB Management and Automation with ClusterControl“, das kostenlos heruntergeladen werden kann.

Überlegungen zur Verwaltung von MongoDB

Integrierte Redundanz

Ein Hauptmerkmal von MongoDB ist die eingebaute Redundanz in Form von Replikation. Wenn Sie zwei oder mehr Datenknoten haben, können diese als Replikatsatz konfiguriert werden, in dem alle Daten, die auf den primären Knoten geschrieben werden, nahezu in Echtzeit auf die sekundären Knoten repliziert werden,

Gewährleistung mehrerer Kopien der Daten. Bei einem primären Failover führen die verbleibenden Knoten im Replikatsatz eine Wahl durch und stufen den Gewinner zum Primärknoten hoch, ein Vorgang, der normalerweise 2 bis 3 Sekunden dauert, und das Schreiben in den Replikatsatz kann fortgesetzt werden. MongoDB verwendet auch ein Journal für schnellere und sicherere Schreibvorgänge auf dem Server oder Replikatsatz und verwendet außerdem eine „Write Concern“-Methode, durch die das Niveau der Schreibredundanz
konfiguriert wird.

Um einen Replikatsatz manuell bereitzustellen, lauten die allgemeinen Schritte wie folgt:

1. Ordnen Sie jedem Datenbankknoten einen einzelnen physischen oder virtuellen Host zu und installieren Sie den MongoDB-Befehlszeilenclient auf Ihrem Desktop. Für eine Konfiguration mit redundantem Replikatsatz sind mindestens drei Knoten erforderlich, von denen mindestens zwei Datenknoten sein werden. Ein Knoten im Replikatsatz kann als Arbiter konfiguriert werden:Dies ist ein Mongod-Prozess, der nur so konfiguriert ist, dass er ein Quorum bildet, indem er bei Bedarf eine Stimme bei der Wahl eines Primary abgibt. Daten werden nicht an Arbiter-Prozesse repliziert.
2. Installieren Sie MongoDB auf jedem Knoten. Einige Linux-Distributionen enthalten MongoDB Community Edition, aber beachten Sie, dass diese möglicherweise nicht die neuesten Versionen enthalten. MongoDB Enterprise ist nur per Download von der MongoDB-Website verfügbar. Eine ähnliche Funktionalität wie MongoDB Enterprise ist auch über Percona Server for MongoDB verfügbar, ein Drop-in-Ersatz für MongoDB Enterprise oder Community Edition.
3. Konfigurieren Sie die einzelnen mongod.conf-Konfigurationsdateien für Ihren Replikatsatz, indem Sie den „Replikationsparameter“ verwenden. Wenn Sie eine Schlüsseldatei für die Sicherheit verwenden, konfigurieren Sie diese jetzt ebenfalls. Beachten Sie, dass die Verwendung der Schlüsseldateisicherheit auch die rollenbasierte Authentifizierung ermöglicht, sodass Sie auch Benutzer und Rollen hinzufügen müssen, um die Server zu verwenden. Starten Sie den Mongod-Prozess auf jedem Server neu.
4. Stellen Sie die Konnektivität zwischen Knoten sicher. Sie müssen sicherstellen, dass MongoDB-Replikatsatzknoten auf Port 27017 miteinander kommunizieren können und dass Ihre Clients auch eine Verbindung zu jedem der Replikatsatzknoten auf demselben Port herstellen können.
5. Verbinden Sie sich mit dem MongoDB-Befehlszeilenclient mit einem der Server und führen Sie rs.initiate() aus, um Ihren Replikatsatz zu initialisieren, gefolgt von rs.add() für jeden zusätzlichen Knoten. rs.conf() kann verwendet werden, um die Konfiguration anzuzeigen.

Obwohl diese Schritte nicht so komplex sind wie das Bereitstellen und Konfigurieren eines MongoDB-Sharding-Clusters oder das Sharding einer relationalen Datenbank, können sie beschwerlich und fehleranfällig sein, insbesondere in größeren Umgebungen.

Skalierbarkeit

MongoDB wird aufgrund seiner Fähigkeit zur horizontalen Skalierung häufig als „webscale“-Datenbanksoftware bezeichnet. Wie bei relationalen Datenbanken ist es möglich, MongoDB vertikal zu skalieren, indem einfach der physische Host, auf dem es sich befindet, mit mehr CPU-Kernen, mehr RAM, schnelleren Festplatten oder sogar einer höheren Busgeschwindigkeit aktualisiert wird. Die vertikale Skalierung hat jedoch ihre Grenzen, sowohl hinsichtlich des Kosten-Nutzen-Verhältnisses und des sinkenden Ertrags als auch der technischen Begrenzung. Um dies zu beheben, verfügt MongoDB über eine „Auto-Sharding“-Funktion, die es ermöglicht, Datenbanken auf viele Hosts (oder Replikatsätze, für Redundanz) aufzuteilen. Während Sharding auch auf relationalen Plattformen möglich ist, es sei denn, dies wurde zu Beginn der Datenbank vorgesehen, erfordert dies eine umfassende Neugestaltung des Schemas und der Anwendung sowie der Neugestaltung der Clientanwendung, was dies zu einem langwierigen, zeitaufwändigen und fehleranfälligen Prozess macht.

MongoDB-Sharding funktioniert durch die Einführung eines Router-Prozesses, über den sich Clients mit dem Sharding-Cluster verbinden, und Konfigurationsservern, die die Cluster-Metadaten und den Speicherort jedes Dokuments im Cluster speichern. Wenn ein Client eine Anfrage an den Router-Prozess sendet, bezieht er sich zunächst auf die Konfigurationsserver, um die Speicherorte der Dokumente zu erhalten, und erhält dann die Abfrageergebnisse direkt von den einzelnen Servern oder
Replikatsätzen (Shards). Sharding wird pro Sammlung durchgeführt.

Ein aus Leistungsgründen äußerst wichtiger Parameter ist hier der „Shard Key“, ein indiziertes Feld oder zusammengesetztes Feld, das in jedem Dokument in einer Sammlung vorhanden ist. Dies definiert die Schreibverteilung über die Shards einer Sammlung. Daher kann sich ein schlecht gewählter Shard-Schlüssel sehr nachteilig auf die Leistung auswirken. Beispielsweise kann ein rein auf Zeitreihen basierender Shard-Schlüssel dazu führen, dass alle Schreibvorgänge über längere Zeiträume an einen einzigen Knoten gehen. Ein gehashter Shard-Schlüssel verteilt zwar Schreibvorgänge gleichmäßig auf Shards, kann sich jedoch auf die Leseleistung auswirken, da ein Resultset von vielen Knoten abgerufen wird.

Schiedsrichter

Ein MongoDB-Arbiter ist ein Mongod-Prozess, der so konfiguriert wurde, dass er nicht als Datenknoten fungiert, sondern nur die Funktion der Abstimmung bereitstellt, wenn ein primärer Replikatsatz gewählt werden soll, um Bindungen zu lösen und sich gegen eine geteilte Abstimmung zu schützen. Ein Arbiter kann nicht primär werden, da er keine Kopie der Daten besitzt oder Schreibvorgänge akzeptiert. Obwohl es möglich ist, mehr als einen Arbiter in einem Replikat-Set zu haben, wird dies im Allgemeinen nicht empfohlen.

Verzögerte Replica-Set-Mitglieder

Verzögerte Mitglieder des Replikatsatzes fügen eine zusätzliche Redundanzebene hinzu und behalten einen Zustand bei, der eine feste Anzahl von Sekunden hinter dem Primären liegt. Da verzögerte Mitglieder ein „laufendes Backup“ oder eine laufende „historische“ Momentaufnahme des Datensatzes sind, können sie bei der Wiederherstellung nach verschiedenen Arten menschlicher Fehler helfen.

Verzögerte Mitglieder sind „versteckte“ Replikatgruppenmitglieder, die für Clientanwendungen unsichtbar sind und daher nicht direkt abgefragt werden können. Sie werden während des normalen Betriebs möglicherweise auch nicht primär und müssen manuell neu konfiguriert werden, falls sie zur Wiederherstellung nach einem Fehler verwendet werden sollen.

Sicherungen

Die Sicherung eines Replica-Sets oder Sharding-Clusters erfolgt über das Kommandozeilen-Dienstprogramm „mongodump“. Bei Verwendung mit dem Parameter --oplog erstellt dies einen Speicherauszug der Datenbank, der ein Oplog enthält, um eine zeitpunktbezogene Momentaufnahme des Zustands einer Mongod-Instanz zu erstellen. Unter Verwendung von mongorestore mit dem Parameter --replayOplog können Sie dann den Datenstatus zum Zeitpunkt des Abschlusses der Sicherung vollständig wiederherstellen und Inkonsistenzen vermeiden.

Für fortgeschrittenere Backup-Anforderungen ist ein Drittanbieter-Tool namens „mongodbconsistent-backup“ – ebenfalls befehlszeilenbasiert – verfügbar, das vollständig konsistente Backups von Sharding-Clustern bereitstellt, ein komplexes Verfahren, da Sharding-Datenbanken auf mehrere Hosts verteilt sind.

Überwachung

Es gibt eine Reihe kommerzieller Tools, sowohl offizielle als auch inoffizielle, die auf dem Markt zur Überwachung von MongoDB erhältlich sind. Diese Tools sind im Allgemeinen Dienstprogramme zur Verwaltung einzelner Produkte, die sich ausschließlich auf MongoDB konzentrieren. Viele konzentrieren sich nur auf bestimmte spezifische Aspekte, wie z. B. das Sammlungsmanagement in einer bestehenden MongoDB-Architektur oder auf Backups oder auf die Bereitstellung. Ohne angemessene Planung kann dies zu einer Situation führen, in der eine Vielzahl zusätzlicher Tools in Ihrer Umgebung bereitgestellt und verwaltet werden muss.

Die mit MongoDB bereitgestellten Befehlszeilentools „mongotop“ und „mongostat“ können eine detaillierte Ansicht der Leistung Ihrer Umgebung bereitstellen und zur Diagnose von Problemen verwendet werden. Darüber hinaus kann der „mongo“-Befehlszeilenclient von MongoDB auch „rs.status()“ – oder in einem Sharded-Cluster „sh.status()“ – ausführen, um den Status von Replikatsätzen oder -clustern und ihren Mitgliedshosts anzuzeigen. Der Befehl „db.stats()“ gibt ein Dokument zurück, das sich mit der Speichernutzung und den Datenvolumina und deren Äquivalenten für Sammlungen sowie anderen Aufrufen für den Zugriff auf viele interne Metriken befasst.

Zusammenfassung

Dies war eine kurze Zusammenfassung der Überlegungen zur Verwaltung von MongoDB. Selbst auf einem so hohen Niveau sollte jedoch sofort klar sein, dass es zwar möglich ist, einen Replikatsatz oder einen Sharded-Cluster über die Befehlszeile mit verfügbaren Tools zu verwalten, dies jedoch nicht in einer Umgebung mit vielen Replikatsätzen oder mit einer großen Produktion skaliert Splitter-Cluster. In mittleren bis großen Umgebungen mit vielen Hosts
und Datenbanken wird es schnell unmöglich, alles mit Befehlszeilentools und Skripten zu verwalten. Während interne Tools und Skripte entwickelt werden können, um die Umgebung bereitzustellen und zu warten, erhöht dies die Last der Verwaltung neuer Entwicklungen, Revisionskontrollsysteme und Prozesse. Ein einfaches Upgrade eines Datenbankservers kann zu einem komplexen Prozess werden, wenn Werkzeugänderungen erforderlich sind, um neue
Datenbankserverversionen zu unterstützen.

Aber wie können wir MongoDB-Cluster ohne interne Tools und Skripte automatisieren und verwalten? Laden Sie das Whitepaper herunter, um zu erfahren, wie!