Planen einer Migration von MongoDB zu Cosmos DB
Nachdem Sie die Vorteile von Cosmos DB geprüft haben, hat Ihr CIO Ihnen grünes Licht für einen Proof of Concept gegeben. Die erste Phase des Projekts ist die Planung der Datenmigration. Dies umfasst das Einrichten einer leeren Cosmos DB-Instanz, um die migrierten Daten zu hosten.
In dieser Lerneinheit durchlaufen Sie die Schritte zur Erstellung einer Cosmos DB-Datenbank und wählen entweder eine Offline- oder Onlinemigrationsmethode aus.
Überprüfen der MongoDB-Kompatibilität
Die erste Aufgabe vor der Migration besteht darin, zu überprüfen, ob Sie von einer unterstützten Version von MongoDB migrieren. Sie können die Unterstützung der neuesten Version auf der folgenden Seite überprüfen:
Azure Cosmos DB-API für MongoDB: Unterstützte Features und Syntax
Um mit der Verwendung einer Cosmos DB in Azure zu beginnen, erstellen Sie ein Cosmos DB-Konto mit der MongoDB-API. Dann erstellen Sie eine Datenbank im Konto. Sie können Ihre Datenbankworkloads in verschiedenen Datenbanken trennen. Ein Vorteil dieses Ansatzes ist die Granularität, mit der Sie den Durchsatz einstellen können.
Der Zugriff auf Ihre Daten wird durch die Verwendung von Azure Virtual Networks (VNet) gesteuert. Sie konfigurieren Ihre VNET-Netzwerksicherheitsgruppe, um die Ports 53, 443, 445, 9354 und 10000-20000 zu öffnen. Natürlich müssen Sie auch Ihre lokalen Firewalls so konfigurieren, dass sie den Zugriff über diese Ports auf Ihren lokalen MongoDB-Server erlauben.
Normalerweise umfasst eine Migration eine umfassende Datenübertragung, und Sie können den Durchsatz während der Migration vorübergehend erhöhen. Wenn Sie den Durchsatz auf Datenbankebene angeben, sollten Sie berücksichtigen, dass jede Sammlung mindestens 100 RU/Sek. benötigt. Daher ist der minimale Wert für RU/Sek. für die Datenbank die Anzahl der Sammlungen multipliziert mit 100. Der Durchsatz auf Datenbankebene erscheint für Migrationsszenarios oft besser geeignet als der Durchsatz auf Sammlungsebene. Sie sollten jedoch bedenken, dass diese Einstellung nach der Erstellung nicht geändert werden kann. Daher sollten Sie die für die erwartete Nutzung der Datenbank nach der Migration am besten geeignete Einstellung auswählen.
Offline- oder Onlinemigrationen
Bei einer Offlinemigration beenden Sie die Verbindungen mit der Datenbank, führen die Migration durch und stellen dann Verbindungen zur neuen migrierten Datenbank her. Sie wird importiert, um Verbindungen während der Migration zu verhindern, da diese Transaktionen verloren gehen.
Bei einer Onlinemigration werden alle Transaktionen, die während der Migration auftreten, auf die neue migrierte Datenbank angewendet. Es gehen keine Transaktionen verloren.
Eine Offlinemigration ist schneller, aber eine Onlinemigration weist eine geringere Downtime auf. Bei der Offlinemigration beginnt die Downtime mit dem Beginn der Migration, bei der Onlinemigration beginnt die Downtime erst am Ende der Migration mit der Übernahme der neuen Datenbank. Sie sollten testweise eine Offlinemigration auf einer Kopie des Livesystems durchführen, um zu untersuchen, ob die Downtime akzeptabel ist. Es könnte möglich sein, die Migration zu einer Zeit durchzuführen, in der die Aktivität normalerweise gering ist. Wenn die Downtime für die Offlinemigration nicht akzeptabel ist, dann wählen Sie die Onlinemigration.
Weitere Informationen zu Onlinemigrationen finden Sie unter Onlinemigration von MongoDB zur Mongo-API von Azure Cosmos DB.
Weitere Informationen zu Offlinemigrationen finden Sie unter Offlinemigration von MongoDB zur Mongo-API von Azure Cosmos DB.