Atlas Live-Migration zum Migrieren von MongoDB zu MongoDB Atlas bereitstellen

Last reviewed 2023-05-08 UTC

In diesem Dokument wird beschrieben, wie Sie die Architektur in Atlas Live-Migration zum Migrieren von MongoDB zu MongoDB Atlas verwenden.

Dieses Dokument richtet sich an Datenbankarchitekten, -administratoren und -entwickler, die an einem vollständig gehosteten MongoDB-Dienst interessiert oder für die Migration von MongoDB-Datenbanken in einem MongoDB-Replikatset zu einem MongoDB Atlas-Cluster verantwortlich sind.

Architektur

Das folgende Diagramm zeigt die Bereitstellungsarchitektur, die Sie in diesem Dokument erstellen:

Grafik: MongoDB-Server in Compute Engine mit dem Migrationspfad vom primären MongoDB Server zu MongoDB Atlas

Im Diagramm stellt der Pfeil den Datenmigrationspfad vom in der Compute Engine ausgeführten MongoDB-Quellreplikatset zum Zielcluster dar, der in MongoDB Atlas in Google Cloud ausgeführt wird. Weitere Informationen zur Architektur finden Sie unter Atlas Live-Migration zum Migrieren von MongoDB zu MongoDB Atlas verwenden.

Lernziele

Eine selbstverwaltete Quelle einrichten, indem Sie ein MongoDB-Beispielreplikatset erstellen und Dokumente in dieses Replikatset laden
Einen Migrationszielcluster in MongoDB Atlas einrichten
Atlas Live-Migration verwenden, um eine Datenbank von Ihrem selbstverwalteten MongoDB-Replikatset in einen vollständig verwalteten MongoDB Atlas-Cluster zu migrieren
Test-, Umstellungs- und Fallback-Strategien verstehen und auswählen

Kosten

Für die Bereitstellung dieser Architektur werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

Compute Engine

Zum Bereitstellen dieser Architektur können Sie nicht die kostenlose Stufe von MongoDB Atlas verwenden. Die verfügbaren Maschinentypen in der kostenlosen Stufe unterstützen Atlas Live-Migration nicht. Für den mindestens erforderlichen Maschinentyp (M10 zum Zeitpunkt der Erstellung dieses Dokuments) fallen in MongoDB Atlas stündliche Dienstkosten an. Informationen zum Generieren einer Preisschätzung finden Sie unter MongoDB Atlas – Preise in der Google Cloud-Preisübersicht. Wenn Sie diese Migration in der Produktion implementieren, empfehlen wir die Verwendung der regulären gehosteten Version von MongoDB Atlas.

Wenn Sie diese Bereitstellung abgeschlossen haben, können Sie laufende Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

Hinweis: Wenn Sie die Ressourcen, die Sie in dieser Bereitstellung erstellen, nicht beibehalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Nachdem Sie die Bereitstellung abgeschlossen haben, können Sie das Projekt löschen, um alle Ressourcen zu entfernen, die mit dem Projekt verknüpft sind.

Zur Projektauswahl
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein. So prüfen Sie, ob die Abrechnung für ein Projekt aktiviert ist.

Selbstverwaltetes MongoDB-Replikatset erstellen

Zum Starten der Bereitstellung installieren Sie das MongoDB-Replikatset in Google Cloud. Diese Datenbank dient als Quelldatenbank. Anschließend prüfen Sie, ob Ihre Quelldatenbank alle erforderlichen Vorbedingungen erfüllt. Mit dieser Prüfung der Vorbedingungen können Sie sich auf die Migration in einer Produktionsumgebung vorbereiten. Auch wenn bereits ein MongoDB-Replikat in Ihrer Produktionsumgebung vorhanden ist, müssen Sie auf Vorbedingungen prüfen.

Nachdem Sie die Prüfung der Vorbedingungen abgeschlossen haben, müssen Sie die Authentifizierung aktivieren und die MongoDB-Quellinstanz neu starten. Um die Migration zu testen, fügen Sie schließlich der MongoDB-Quellinstanz ein Stichproben-Dataset hinzu, das in die Zieldatenbank migriert wird.

MongoDB-Replikatset installieren

Gehen Sie im Google Cloud Marketplace zur Installation des MongoDB-Replikatsets in Compute Engine.

MongoDB im Cloud Marketplace aufrufen
Klicken Sie auf Starten. Da mehrere Google Cloud APIs aktiviert sind, kann der Startvorgang eine Weile dauern.

Wenn Sie Berechtigungen für mehrere Projekte haben, wird eine Liste dieser Projekte angezeigt. Wählen Sie das Projekt für Ihre MongoDB-Installation aus.

Ein MongoDB-Replikatset wird auf einer Reihe von Compute Engine-Instanzen gemäß einer Deployment Manager-Vorlage bereitgestellt.
Übernehmen Sie alle Einstellungen für die Standardkonfiguration.
Klicken Sie auf Bereitstellen.
Aktivieren Sie Cloud Shell in der Google Cloud Console.

Cloud Shell aktivieren

Unten in der Google Cloud Console wird eine Cloud Shell-Sitzung gestartet und eine Eingabeaufforderung angezeigt. Cloud Shell ist eine Shell-Umgebung, in der das Google Cloud CLI bereits installiert ist und Werte für Ihr aktuelles Projekt bereits festgelegt sind. Das Initialisieren der Sitzung kann einige Sekunden dauern.
Verwenden Sie eine SSH-Verbindung, um sich bei der Compute Engine-Instanz anzumelden, auf der das primäre MongoDB-Replikat ausgeführt wird:
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Dabei gilt:
- MONGODB_VM_NAME ist der Name des primären Replikats des MongoDB-Replikatsets.
- PROJECT_ID ist der Name Ihres Google Cloud-Projekts.
- ZONE_OF_VM ist die Zone, in der sich Ihre VM-Instanz befindet. Weitere Informationen finden Sie unter Geografie und Regionen.
Wenn ein SSH-Schlüssel generiert wird, fragt das System nach einer Passphrase. Wenn Sie keine Passphrase angeben möchten, drücken Sie Enter. Wenn Sie eine Passphrase angeben, notieren Sie sich diese für später.

Wenn Sie mit Cloud Shell keine Verbindung herstellen können, klicken Sie im Deployment Manager auf SSH to a servers tier VM.
Starten Sie die mongo-Shell:
```
mongo
```
Listen Sie die vorhandenen Datenbanken auf:
```
show dbs
```
Die Ausgabe sieht etwa so aus:
```
admin   0.000GB
config  0.000GB
local   0.000GB
```
Lassen Sie die mongo-Shell für anstehende Befehle geöffnet.

Sie haben jetzt Ihr MongoDB-Replikatset erstellt, darauf zugegriffen und bestätigt, dass es betriebsbereit ist.

Vorbedingungen für die Quelldatenbank prüfen

Atlas Live-Migration erfordert, dass das MongoDB-Quellreplikatset bestimmte Konfigurationskriterien oder Vorbedingungen erfüllt. Auch wenn das MongoDB-Quellreplikatset, das Sie im Rahmen dieser Bereitstellung installiert haben, der erforderlichen Version entspricht, müssen Sie in einer Produktionsumgebung immer noch auf Vorbedingungen prüfen. Die Vorbedingungsprüfungen werden in der Atlas-Dokumentation beschrieben.

So prüfen Sie, ob alle Voraussetzungen erfüllt sind:

Prüfen Sie in der mongo-Shell, ob die Version von MongoDB 2.6 oder höher ist. In einer Produktionsdatenbankinstanz öffnen Sie die mongo-Shell, stellen über eine SSH-Verbindung eine Verbindung zum MongoDB-Server her und führen dann diesen Befehl aus, um die Version zu ermitteln.
```
db.version()
```
In der Ausgabe wird die Version angezeigt. Wenn Ihre Version älter als 2.6 ist, müssen Sie die Upgrade-Anleitung befolgen.
Prüfen Sie, ob Ihre aktuelle Bereitstellung ein MongoDB-Replikatset ist:
```
rs.status()
```
Die Ausgabe ist ein Status für das MongoDB-Replikatset. Die folgende Ausgabe zeigt, dass eine MongoDB-Instanz ohne aktiviertes MongoDB-Replikatset gestartet wurde.
```
{
    "ok" : 0,
    "errmsg" : "not running with --replSet",
    "code" : 76,
    "codeName" : "NoReplicationEnabled"
}
```
Beenden und starten Sie in diesem Fall die MongoDB-Instanz mit aktiviertem MongoDB-Replikatset neu. Wenn Sie eine eigenständige Instanz von MongoDB haben, aktualisieren Sie die MongoDB-Instanz auf ein MongoDB-Replikatset.
Prüfen Sie, ob die Authentifizierung für Ihren Quellcluster aktiviert ist. Dazu melden Sie sich an:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Dabei gilt:
- YOUR_ADMIN_USERNAME ist der Nutzername des Administrators Ihrer Bereitstellung.
Für das zuvor erstellte MongoDB-Replikatset ist die Authentifizierung nicht aktiviert.

Folgen Sie in diesem Fall der Anleitung zum Aktivieren der Authentifizierung. Im Folgenden finden Sie einen Beispielbefehl zur Aktivierung der Authentifizierung mit einem Beispielnutzernamen und -passwort:
```
use admin
db.createUser(
  {
    user: "myUserAdmin",
    pwd: "myUserAdminPassword",
    roles: [ { role: "userAdminAnyDatabase", db: "admin" }, "readWriteAnyDatabase", "clusterMonitor" ]
  }
)
```
Nachdem die Authentifizierung aktiviert wurde, ist die MongoDB-Rolle clusterMonitor erforderlich, um rs.status() auszuführen. Der vorherige Befehl gibt diese Rolle an.
Prüfen Sie, ob der Administrator die richtigen Rollen für die Version des MongoDB-Replikatsets hat. Eine Liste der Rollen, die einer bestimmten Version entsprechen, finden Sie in der Dokumentation zur Quellclustersicherheit in der Dokumentation zu Atlas Live-Migration.
```
use admin
db.getUser("YOUR_ADMIN_USERNAME")
```
Der Nutzername muss in Anführungszeichen gesetzt werden.
(Optional) Wenn Ihre MongoDB-Bereitstellung auf einer früheren Version als 4.2 basiert, enthält sie Indexe mit Schlüsseln, die die Beschränkung für Indexschlüssel von 1.024 Byte überschreiten. Legen Sie in diesem Fall den MongoDB-Serverparameter failIndexKeyTooLong auf false fest, bevor Sie das Verfahren der Atlas Live-Migration starten.

Nachdem Sie die Vorbedingungen geprüft und die erforderlichen Änderungen vorgenommen haben, schließen Sie die Konfigurationen ab und starten die Datenbank neu. Dies wird im nächsten Abschnitt beschrieben.

Authentifizierung aktivieren und den MongoDB-Replikatsatz neu starten

Um die Authentifizierung zu aktivieren, erstellen Sie Schlüsseldateien und einen Administrator. In einer Produktionsumgebung können Sie mithilfe von Skripts den Prozess automatisieren.

Erstellen Sie in Cloud Shell eine Schlüsseldatei:
```
openssl rand -base64 756 > PATH_TO_KEY_FILE
```
Dabei gilt:
- PATH_TO_KEY_FILE: der Speicherort Ihres SSH-Schlüssels, z. B. /etc/mongo-key
Aktivieren Sie die Autorisierung für jede der drei VMs:
1. Kopieren Sie die Schlüsseldatei auf die VM:
```
gcloud compute copy-files PATH_TO_KEY_FILE NAME_OF_THE_VM:PATH_TO_KEY_FILE --zone=ZONE_OF_VM
```
  Dabei gilt:
  - NAME_OF_THE_VM: der Name einer der VMs, auf der ein Replikat des Replikatsets ausgeführt wird.
  - ZONE_OF_VM: die Google Cloud-Zone, in der sich die VM befindet und auf die in NAME_OF_THE_VM verwiesen wird.
2. Verwenden Sie eine SSH-Verbindung, um sich bei der VM anzumelden und den Inhaber sowie die Zugriffsberechtigungen der Schlüsseldatei zu ändern:
```
sudo chown mongodb:mongodb PATH_TO_KEY_FILE

sudo chmod 400 PATH_TO_KEY_FILE
```
3. Öffnen Sie in Ihrem bevorzugten Texteditor die Datei mongod.conf im Bearbeitungsmodus. Wenn Sie Änderungen zurückschreiben möchten, müssen Sie möglicherweise den Befehl sudo verwenden, um den Texteditor zu starten.
4. Bearbeiten Sie den Abschnitt security der Datei mongod.conf:
```
security:
  authorization: enabled
  keyFile: PATH_TO_KEY_FILE
```
5. Starten Sie das Replikat neu:
```
sudo service mongod restart
```
Prüfen Sie, ob Sie sich beim primären MongoDB-Replikatset anmelden können:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```

Beispieldaten einfügen

In den folgenden Schritten fügen Sie Beispieldaten in die Quelldatenbank ein und prüfen dann, ob die Dokumente erfolgreich eingefügt wurden:

Verwenden Sie in Cloud Shell ssh, um eine Verbindung zur primären Compute Engine-Instanz von MongoDB herzustellen:
```
gcloud compute ssh MONGODB_VM_NAME --project PROJECT_ID --zone ZONE_OF_VM
```
Möglicherweise müssen Sie die Passphrase für den SSH-Schlüssel angeben.
Starten Sie die mongo-Shell:
```
mongo -u YOUR_ADMIN_USERNAME -p --authenticationDatabase admin
```
Geben Sie das Passwort an, das Sie beim Erstellen des Nutzernamens des Administrators festgelegt haben.
Erstellen Sie eine Datenbank:
```
use migration
```
Erstellen Sie eine Sammlung:
```
db.createCollection("source")
```
Prüfen Sie, ob die Sammlung leer ist:
```
db.source.count()
```

Fügen Sie die folgenden fünf Dokumente als ersten Datensatz hinzu:

db.source.insert({"document_number": 1})
db.source.insert({"document_number": 2})
db.source.insert({"document_number": 3})
db.source.insert({"document_number": 4})
db.source.insert({"document_number": 5})

Die Ausgabe für jeden dieser Befehle sieht in etwa so aus:

WriteResult({ "nInserted" : 1 })

Prüfen Sie, ob Sie die fünf Dokumente erfolgreich zur Sammlungsmigration hinzugefügt haben. Das Ergebnis muss 5 sein.
```
db.source.count()
```
Nachdem die Datenbankmigration eingerichtet und gestartet wurde, werden diese Dokumente in den Zielcluster in MongoDB Atlas migriert.

Cluster in MongoDB Atlas erstellen

Ein MongoDB-Replikatset wird in MongoDB Atlas als Cluster bezeichnet. Wenn Sie keinen Cluster als Zieldatenbank eingerichtet haben, folgen Sie der Anleitung in diesem Abschnitt. Diese Schritte basieren auf der MongoDB-Dokumentation. Wenn Sie bereits einen Cluster als Zieldatenbank eingerichtet haben, können Sie diesen Abschnitt einfach überspringen.

Rufen Sie im Cloud Marketplace die Seite MongoDB Atlas – Free Tier auf.

MongoDB Atlas im Marketplace
Klicken Sie auf Zum Registrieren die Website MongoDB aufrufen.
Klicken Sie auf Launch your first cluster.
Geben Sie die erforderlichen Informationen ein und klicken Sie dann auf Get started free. Notieren Sie sich die von Ihnen angegebenen Informationen.
Klicken Sie auf Advanced Configuration Options.
Wählen Sie für Cloud Provider & Region die Option Google Cloud Platform und Iowa (us-central1) aus.
Klicken Sie auf den Tab Cluster Tier und wählen Sie dann M10 aus.
Klicken Sie auf den Tab Cloud Provider & Region, wählen Sie MongoDB 4.0 or MongoDB 4.2 aus und deaktivieren Sie die Sicherung.
Klicken Sie auf Create Cluster.

Warten Sie, bis die Erstellung des Clusters abgeschlossen ist. Der Projektname ist Project 0 (mit Leerzeichen) und der Clustername Cluster0 (ohne Leerzeichen).

Der Zielcluster wird in MongoDB Atlas eingerichtet und ausgeführt.

Failover des MongoDB Atlas-Clusters testen

Nach Abschluss der Migration führt der Cluster in MongoDB Atlas einen rollierenden Neustart durch. Jedes Clustermitglied wird der Reihe nach neu gestartet. Testen Sie das Failover, um zu gewährleisten, dass dieser Prozess funktioniert.

Live-Migration starten

So migrieren Sie die Daten von der Quelle zur Zieldatenbank:

Melden Sie sich in MongoDB Atlas an.
Rufen Sie die Seite Clusters auf und wählen Sie den Cluster aus, zu dem Sie migrieren möchten.
Klicken Sie im Zielclusterbereich (Cluster 0) auf .
Wählen Sie Migrate Data to this Cluster aus.
Prüfen Sie die Informationen im sich öffnenden Fenster. Wenn Sie bereit für die Migration sind, klicken Sie auf I'm ready to migrate.

Ein Fenster mit einer Anleitung zur Datenmigration wird angezeigt. Die aufgeführten IP-Adressen müssen auf das MongoDB-Replikatset zugreifen können. Wenn Sie keine Firewallregel für diese Adressen erstellt haben, fügen Sie mit Cloud Shell eine Firewallregel basierend auf diesem Beispielbefehl hinzu:
```
gcloud compute firewall-rules create "allow-mongodb-atlas" --allow=tcp:27027 --source-ranges="35.170.231.208/32,3.92.230.111/32,3.94.238.78/32,54.84.208.96/32" --direction=INGRESS
```
Geben Sie im Feld Hostname: Port of the primary of your replica set die IP-Adresse und den Port des primären Replikatsets ein, z. B. IP_ADDRESS:PORT_FOR_PRIMARY.
1. Führen Sie den folgenden Befehl in der mongo-Shell auf jeder Instanz aus, die in Ihrem Google Cloud-Projekt ausgeführt wird, um die primäre Instanz zu ermitteln:
```
rs.isMaster().primary
```
2. Die entsprechende externe IP-Adresse finden Sie auf der Seite VM-Instanzen von Compute Engine. Der Standard-MongoDB-Port ist 27017.
Geben Sie den Nutzernamen und das Passwort des Administrators Ihres MongoDB-Replikatsets ein. Übernehmen Sie für alle anderen Einstellungen die Standardwerte.
Klicken Sie auf Validieren und führen Sie einen der folgenden Schritte aus:
- Wenn die Validierung erfolgreich ist, klicken Sie auf Migration starten.
- Wenn die Validierung fehlschlägt, führen Sie die Fehlerbehebung anhand der Anleitung durch. Wenn MongoDB Atlas beispielsweise keine Verbindung zum MongoDB-Replikatset herstellen kann, werden die IP-Adressen angegeben, von denen MongoDB Atlas versucht, eine Verbindung herzustellen. Fügen Sie für diese Adressen eine Firewallregel hinzu, die TCP-Traffic auf Port 27017 für die Server des MongoDB-Replikatsets zulässt.
Der MongoDB Atlas-Bildschirm zeigt den Validierungsfortschritt an. Warten Sie, bis die Meldung Erste Synchronisierung ist abgeschlossen! in der Statusleiste angezeigt wird.

Der erste Ladevorgang aus dem MongoDB-Replikatset ist jetzt abgeschlossen. Der nächste Schritt besteht darin, zu prüfen, ob dieser Ladevorgang erfolgreich war.

Nachdem die erste Migration abgeschlossen ist, liefert MongoDB Atlas eine Schätzung der verbleibenden Stunden, bis Sie die Umstellung auf den Zielcluster vornehmen müssen. Möglicherweise erhalten Sie auch eine E-Mail mit Anweisungen von MongoDB, wie Sie die verbleibende Zeit verlängern können. Außerdem enthält diese E-Mail eine Warnung darüber, dass die Migration abgebrochen wird, wenn die endgültige Umstellung nicht innerhalb der angegebenen Zeit erfolgt.

Datenbankmigration prüfen

Es ist wichtig, eine Strategie zur Prüfung der Datenbankmigration zu entwerfen und zu implementieren, um zu bestätigen, dass die Datenbankmigration erfolgreich ist. Die jeweilige Prüfstrategie hängt zwar von Ihrem konkreten Anwendungsfall ab, wir empfehlen Ihnen jedoch, die folgenden Prüfungen durchzuführen:

Vollständigkeitsprüfung. Prüfen Sie, ob die erste Dokumentgruppe erfolgreich aus den Quelldatenbanken migriert wurde (erster Ladevorgang).
Dynamische Prüfung. Prüfen Sie, ob Änderungen in den Quelldatenbanken in die Zieldatenbanken übertragen werden (laufende Migration).

Prüfen Sie zuerst, ob der erste Ladevorgang erfolgreich war:

Klicken Sie in MongoDB Atlas auf Clusters.
Klicken Sie auf Collections.
Prüfen Sie, ob eine Datenbank mit dem Namen migrations vorhanden ist und die Sammlung mit dem Namen source fünf Dokumente enthält.

Prüfen Sie als Nächstes, ob laufende Änderungen an den Quelldatenbanken in den Zieldatenbanken übernommen werden:

Verwenden Sie in Cloud Shell eine SSH-Verbindung, um sich bei der primären VM des MongoDB-Quellreplikatsets anzumelden.
Starten Sie die mongo-Shell:
```
mongo
```

Fügen Sie ein weiteres Dokument ein:

use migration
db.source.insert({"document_number": 6})

Klicken Sie auf der Seite MongoDB Atlas Collections zur Migrationssammlung auf Refresh, um zu sehen, dass ein Dokument zur Sammlung source hinzugefügt wird.

Sie haben jetzt überprüft, ob Atlas Live-Migration automatisch alle Originaldaten aus der Quelle und alle laufenden Änderungen an der Quelle migriert hat.

Atlas-Zielcluster testen

In einer Produktionsumgebung ist es wichtig, Anwendungen zu testen, die auf Zieldatenbanken zugreifen, um dafür zu sorgen, dass sie ordnungsgemäß funktionieren. In diesem Abschnitt werden verschiedene Teststrategien erläutert.

Anwendungen während der Migration mit einer Zieldatenbank testen

Wie im vorherigen Abschnitt gezeigt, können Sie Anwendungstests während einer laufenden Datenbankmigration durchführen. Dieser Ansatz funktioniert möglicherweise, wenn Anwendungen das Ziel nicht so ändern, dass es mit Daten aus den Quelldatenbanken in Konflikt steht. Ob dieser Ansatz für Sie infrage kommt, hängt von Ihrer Umgebung und den Abhängigkeiten ab. Wenn die Testanwendung Daten in die Zieldatenbank schreibt, kann dies einen Konflikt mit der laufenden Migration verursachen.

Anwendungen mit einer temporären Zieldatenbank testen

Wenn Sie Anwendungen während der Migration einer Produktionsdatenbank nicht testen können, können Sie die Daten in temporäre Zieldatenbanken migrieren, die nur zu Testzwecken verwendet werden, und dann die Testziele nach einer Testmigration löschen.

Bei dieser Methode halten Sie die Testmigration irgendwann an (als wäre die Datenbankmigration abgeschlossen) und testen die Anwendungen anhand dieser Testdatenbanken. Nach Abschluss des Tests löschen Sie die Zieldatenbanken und starten die Migration der Produktionsdatenbank, um die Daten in permanente Zieldatenbanken zu migrieren. Der Vorteil dieser Strategie besteht darin, dass die Zieldatenbanken gelesen und geschrieben werden können, da sie nur zu Testzwecken dienen.

Anwendungen nach Abschluss der Migration mit einer Zieldatenbank testen

Wenn keine der vorherigen Strategien infrage kommt, haben Sie die Möglichkeit, die Anwendung nach Abschluss der Migration in der Datenbank zu testen. Wenn sich alle Daten in den Zieldatenbanken befinden, testen Sie die Anwendungen, bevor Sie sie den Nutzern zur Verfügung stellen. Wenn die Prüfung das Schreiben von Daten umfasst, ist es wichtig, dass Testdaten und keine Produktionsdaten geschrieben werden, um Inkonsistenzen in den Produktionsdaten zu vermeiden. Um Dateninkonsistenzen oder überflüssige Daten in der Zieldatenbank zu vermeiden, müssen die Testdaten nach Abschluss der Tests entfernt werden.

Es wird empfohlen, die Zieldatenbanken zu sichern, bevor sie für den Produktionszugriff durch Anwendungssysteme geöffnet werden. Mit diesem Schritt wird gewährleistet, dass es einen konsistenten Ausgangspunkt gibt, den Sie bei Bedarf neu erstellen können.

Vom MongoDB-Quellreplikat auf den Zielcluster umschalten

Nachdem Sie alle Tests abgeschlossen und geprüft haben, ob laufende Änderungen in der Zieldatenbank übernommen werden, können Sie die Umstellung planen.

Zuerst müssen Sie alle Änderungen an der Quelldatenbank anhalten, damit Atlas Live-Migration die noch nicht migrierten Änderungen am Ziel übernehmen kann. Nachdem alle Änderungen im Ziel erfasst wurden, können Sie die Umstellung von Atlas Live-Migration einleiten. Nach Abschluss dieses Vorgangs können Sie von der Quell- zur Zieldatenbank wechseln.

Klicken Sie in MongoDB Atlas auf Clusters.
Klicken Sie im Bereich Cluster0 auf Prepare to Cutover. Eine detaillierte Erklärung des Umstellungsprozesses und ein Verbindungsstring zum Zielcluster werden angezeigt.
Klicken Sie auf Cut over.

Wenn die Migration abgeschlossen ist, wird die Meldung Success! Your cluster migration is complete angezeigt.

Sie haben Ihr MongoDB-Replikatset jetzt erfolgreich zu einem MongoDB Atlas-Cluster migriert.

Fallback-Strategie vorbereiten

Nach einer Umstellung ist der Zielcluster das Erfassungssystem. Die Quelldatenbanken sind veraltet und werden schließlich entfernt. Sie sollten jedoch bei schwerwiegenden Fehlern in den neuen Zieldatenbanken auf die Quelldatenbanken zurückgreifen. Ein Fehler kann beispielsweise auftreten, wenn die Geschäftslogik in einer Anwendung nicht während des Tests ausgeführt wird und später nicht ordnungsgemäß funktioniert. Ein weiterer Fehler kann auftreten, wenn das Leistungs- oder Latenzverhalten nicht mit den Quelldatenbanken übereinstimmt und Fehler verursacht.

Um die Auswirkungen solcher Fehler möglichst gering zu halten, sollten Sie die ursprünglichen Quelldatenbanken bei Änderungen an der Zieldatenbank auf den neuesten Stand bringen. Atlas Live-Migration bietet keinen Fallback-Mechanismus. Weitere Informationen zu Fallback-Strategien finden Sie unter Datenbankmigration: Konzepte und Prinzipien (Teil 2).

Bereinigen

In den folgenden Abschnitten wird erläutert, wie Sie zukünftige Gebühren für Ihr Google Cloud-Projekt und die MongoDB-Ressourcen vermeiden können, die Sie in dieser Bereitstellung verwendet haben.

Google Cloud-Projekt löschen

Damit Ihrem Google Cloud-Konto die in dieser Bereitstellung verwendeten Ressourcen nicht in Rechnung gestellt werden, können Sie das Google Cloud-Projekt löschen.

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:

Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.

Wenn Sie mehrere Architekturen, Anleitungen und Kurzanleitungen durcharbeiten möchten, können Sie die Überschreitung von Projektkontingenten verhindern, indem Sie Projekte wiederverwenden.

Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
Zur Seite „Ressourcen verwalten“
Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

MongoDB Atlas-Cluster pausieren oder beenden

Wenn Sie weitere Gebühren für den MongoDB Atlas-Cluster vermeiden möchten, müssen Sie den Cluster pausieren oder beenden. Weitere Informationen zu den Auswirkungen auf die Abrechnung finden Sie unter Pause or Terminate a Cluster.

Nächste Schritte

Inhalte zur Datenmigration in Google Cloud ansehen
Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.