MongoDB Atlas ist ein MongoDB Cloud Dienst, der von denselben Leuten entwickelt und betrieben wird, die auch die Datenbank entwickeln.
In dem Dienst sind die gesammelten Best-Practices von tausenden Kundenimplementierungen vereint.
Kunden können auf MongoDB Atlas mit der Zuversicht aufsetzen, daß man sich nicht länger um das Setup, die Konfiguration, das Management, Updates, Monitoring oder andere Aspekte des betriebs eines zuverlässigen Datenbank-Clusters kümmern muß.
MongoDB hat den Dienst im Juli 2016 gestartet und ist seitdem damit sehr erfolgreich.
Tausende Kunden nutzen ihn, seit dem, um hochgradig sichere, hochgradig skalierbare und performante MongoDB Datenbanken zu betreiben.
Zu den Highlights, unter den Features, gehört die Möglichkeit Replica Sets bei allen großen Cloud Providers (AWS, Azure, Google) zu erstellen und Datenbank-Cluster zu deployen, die mehrere Cloud-Regionen umspannen.
Diese Serie soll die Schritte erklären, die man befolgen sollte um von lokal betrieben MongoDB Datenbanken nach MongoDB Atlas zu migrieren.
- Reisevorbereitungen
Egal wo man hin will, vor dem Antritt einer Reise ist es grundsätzlich eine gute Idee sich etwas Zeit für die Reisevorbereitungen zu nehmen.
Ein Teil davon wird es sein, sich verschiedene Optionen für die Migration der Daten anzusehen.
Über ein paar Punkte müssen wir uns aber vorher im klar werden.
1. Sie wollen ihre Daten in MongoDB Atlas hosten, ansonsten brauchen sie nicht unbedingt weiterlesen.
2. Sie haben ihre Daten bereits in einer MongoDB. Wenn nicht ist das auch nicht so schlimm, allerdings benötigt dies weitere Schritte, die wir an dieser Stelle mal außen vor lassen.
3. Sie nutzen MongoDB in der Version 3.0 oder höher. MongoDB Atlas unterstützt immer die aktuellsten MongoDB Versionen, es ist daher evtl. notwendig eine lokale Datenbank - vor der Migration- zu updaten.
Die Dokumentation bietet hierzu Hilfestellung:
https://docs.mongodb.com/manual/release-notes/3.0-upgrade/
https://docs.mongodb.com/manual/release-notes/3.2-upgrade/
https://docs.mongodb.com/manual/release-notes/3.4-upgrade/
https://docs.mongodb.com/manual/release-notes/3.6/
4. Sie nutzen ein Replica Set oder einen Sharded Cluster. Grundsätzlich ist es auch möglich ein Standalone Deployment zu betreiben, aber das steht hier nicht im Fokus.
Ab diesem Punkt gibt es vier Möglichkeiten die Daten zu migrieren:
- Live Import
Funktioniert vollständig automatisiert, über die Atlas Administrationsoberfläche.
Downtime: minimal, lediglich beim Umstellen der Datenbankverbindung.
- mongomirror
Hierbei handelt es sich um ein Tool für die Migration von Daten aus einem lokalen MongoDB Replica Set in ein MongoDB Atlas Replica Set.
Downtime: minimal, lediglich beim Umstellen der Datenbankverbindung.
- mongorestore
Hierbei handelt es sich um Kommandozeilenprogramm, das Daten entweder aus einem binären Datenbank Dump (erstellt mit mongodump) oder dem Standard-Input laden kann
Downtime: während des backups und einspielens der Daten
- mongoimport
Hierbei handelt es sich um ein Kommandozeilenprogramm, das Inhalte aus JSON, CSV oder TSV Dateien importieren kann.
Downtime: während des backups und einspielens der Daten
Für einen Großteil der Installationen ist Live Import die beste und effizienteste Art, Daten nach MongoDB Atlas zu migrieren.
Es bietet die Möglichkeit einen existierenden Cluster, während des Prozesses, weiter zu betreiben.
Es gibt allerdings ein paar Punkte zu bedenken. z.B. sollte der existierende Cluster sollte nicht übermäßig unter Last stehen, oder, wenn man geographisch sehr weit vom AWS-US-WEST Rechenzentrum entfernt ist kann es zu sehr großen Latenzen kommen.
Für die einzelnen Punkte verlinke ich hier auf die jeweiligen Erläuterungen des Herstellers.
Problem: Zu wenig RAM im Ziel-Cluster
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#insufficient
Lösung: Berechnen des benötigten RAM und erhöhen des RAM für den Migrationsprozess
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#increase
Referenz: wie errechne ich den benötigten RAM für meine MongoDB Anwendung
https://docs.mongodb.com/manual/faq/diagnostics/#what-is-a-working-set
Problem: Zu hohe Netzwerklatenz zwischen Quelle und Ziel
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#latency
Lösung: Latenz reduzieren oder mongodump/mongorestore statt Live Import nutzen
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#reduce
Problem: Netzwerkprobleme aufgrund fehlender Konfigurationen an Whistlists und Firewalls
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#netwrokaccess
Lösung: Sicherstellen, daß die MongDB Live Import Server ge-whitelstetd sind und die Firewalls eine Verbindung zulassen
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#liveimport
Problem: Fehlende Berechtigungen auf der Datenbank
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#userrights
Lösung: Sicherstellen das authentication eingeschaltet ist und die benötigten Benutzer entsprechende Rechte haben
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#ensure
Problem: Zu geringe Größe des Oplogs auf dem Zielsystem
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#insufficientoplog
Lösung: Die Größe des Oplogs an die Anforderungen der Applikation anpassen
https://www.mongodb.com/blog/post/charting-a-course-to-mongodb-atlas-part-one-preparing-for-the-journey#size
Referenz: Größe des Oplog anpassen
https://docs.mongodb.com/manual/core/replica-set-oplog/index.html#oplog-status
