Bewährte Verfahren für die Datenbankmigration

Die Migration einer Datenbank ist komplexer als das Verschieben einer VM, da Datenbanken zustandsbehaftet sind und häufig rund um die Uhr aktive Verbindungen haben. Ein einfaches Kopieren und Wiederherstellen würde mehrere Stunden Ausfallzeit erfordern, was für Produktionssysteme nicht akzeptabel ist. Bei einer bewährten Datenbankmigration werden die Daten kontinuierlich repliziert, damit Quelle und Ziel während der Validierung des Ziels synchron bleiben. Anschließend erfolgt eine kurze, geplante Umschaltung, bei der der Datenverkehr an die neue Azure-Datenbank weitergeleitet wird.

Azure Database Migration Service (DMS) ist ein vollständig verwalteter Dienst, der Online-Migrationen (nahezu ohne Ausfallzeit) und Offline-Migrationen (mit Ausfallzeit) von gängigen lokalen Datenbank-Engines zu verwalteten Azure-Datenbankdiensten orchestriert. DMS unterstützt unter anderem die Quellen SQL Server, MySQL, PostgreSQL, MongoDB, Oracle sowie die Ziele Azure SQL Database, Azure SQL Managed Instance, Azure Database for MySQL und Azure Cosmos DB. Der Dienst ist für Prüfungen der Kompatibilität vor der Migration in Data Migration Assistant (DMA) integriert.

Führen Sie vor der Migration von SQL Server Data Migration Assistant (DMA) für die Quelldatenbank aus. DMA erkennt: Kompatibilitätsprobleme (in Ihrer Datenbank verwendete Features, die vom Azure-SQL-Ziel nicht unterstützt werden), inkompatible Änderungen, veraltete Features und Leistungsempfehlungen. Das Tool erstellt einen detaillierten HTML-Bericht und priorisiert die Probleme nach ihrem Schweregrad, damit Ihr Team sie vor Beginn des Migrationsfensters beheben kann.

Bei einer Offline-Migration wird die Quelldatenbank für die gesamte Dauer der Migration offline genommen — dies ist für kleine Datenbanken oder unkritische Systeme akzeptabel, bei denen ein Wartungsfenster möglich ist. Eine Online-Migration verwendet Change Data Capture (CDC) oder die Übertragung von Transaktionsprotokollen, um Änderungen kontinuierlich zu replizieren, während die neue Datenbank geladen wird. Dadurch beschränkt sich die Ausfallzeit auf den abschließenden Umschaltungsschritt. Eine Online-Migration wird für Datenbanken mit mehr als 1 GB oder mit SLAs empfohlen, die weniger als 1 Stunde Ausfallzeit vorgeben.

Ein DMS-Migrationsprojekt definiert die Quellverbindung (Servername, Authentifizierung, Datenbanknamen), die Zielverbindung (Azure-SQL-Verbindungszeichenfolge) und den Migrationsmodus (online oder offline). Außerdem wählen Sie die zu migrierenden Datenbanken und Tabellen aus. DMS überprüft die Konnektivität vor dem Start. Das Migrationsprojekt bleibt im Azure-Portal erhalten, sodass Sie den Fortschritt überwachen, fehlgeschlagene Tabellen erneut versuchen und detaillierte Aktivitätsprotokolle anzeigen können.

Migrieren Sie immer zuerst das Schema und danach die Daten. Verwenden Sie DMA oder SQL Server Management Studio (SSMS), um Tabellen, Sichten, gespeicherte Prozeduren, Funktionen und Indizes zu skripten und in der Azure SQL Database bereitzustellen. Überprüfen Sie, ob alle Schemaobjekte vorhanden sind und fehlerfrei kompiliert werden, bevor DMS mit der Datenübertragung beginnt. Während der Migration entdeckte Schemafehler können den Migrationslauf beschädigen und einen Neustart von Grund auf erforderlich machen.

DMS führt ein vollständiges Laden der Daten durch, indem der Quelldatenbank Tabelle für Tabelle gelesen und die Zeilen per Bulk Insert in das Azure-SQL-Ziel geschrieben werden. Während des vollständigen Ladens verarbeitet der Dienst große Tabellen, indem er sie in Batches aufteilt. Indizes auf dem Zielsystem werden während des Ladens deaktiviert, um den Durchsatz zu maximieren, und anschließend neu erstellt. Bei sehr großen Datenbanken (im TB-Bereich) sollten Sie Azure Data Factory oder bacpac-Exporte verwenden, um Daten vorab zu laden und die Laufzeit von DMS zu verkürzen.

Bei Online-Migrationen aktiviert DMS SQL Server Change Data Capture (CDC) auf der Quelle, um INSERT-, UPDATE- und DELETE-Vorgänge zu erfassen, die während des vollständigen Ladens stattfinden. Sobald das vollständige Laden abgeschlossen ist, spielt DMS die erfassten Änderungen auf dem Ziel ein und schließt die Lücke schrittweise. Wenn die Latenz nahezu null erreicht, ist die Datenbank für den Cutover bereit. Für CDC muss der SQL Server Agent ausgeführt werden, und die Quelldatenbank muss sich im Full-Recovery-Modus befinden.

Wenn der CDC-Rückstand minimal ist, starten Sie den Cutover im DMS-Portal. DMS nimmt keine neuen CDC-Ereignisse mehr an, wendet die verbleibenden Änderungen an und markiert die Migration als abgeschlossen. Anschließend leiten Sie die Verbindungszeichenfolgen der Anwendung an den Azure-SQL-Endpunkt um. Führen Sie für kritische Tabellen Datenvalidierungsabfragen aus, die Zeilenanzahlen und Prüfsummenaggregate von Quelle und Ziel vergleichen. Belassen Sie die Quelldatenbank nach dem Cutover 24–48 Stunden im schreibgeschützten Modus, falls ein Rollback erforderlich wird.

Nach der Migration kann sich Azure SQL Database anders verhalten als SQL Server lokal, da sich Abfrageplancaches, Statistiken und Hardware unterscheiden. Führen Sie den Database Experimentation Assistant (DEA) aus, um Workload-Ablaufprotokolle auf dem Azure-Ziel wiederzugeben und Ausführungspläne zu vergleichen. Aktivieren Sie Automatic Tuning in Azure SQL, damit der Dienst automatisch Indizes erstellt oder entfernt und Abfragepläne ohne Regression erzwingt. So wird die Leistung im Laufe der Zeit ohne manuellen Eingriff verbessert.

DMS migriert auch Open-Source-Engines: MySQL zu Azure Database for MySQL mithilfe des Musters mysqldump + binlog replication und PostgreSQL zu Azure Database for PostgreSQL mithilfe logischer Replikationsslots. Verwenden Sie für Migrationen von MongoDB zu Cosmos DB die Cosmos-DB-for-MongoDB-API und die native Pipeline aus mongodump / mongorestore oder den MongoDB-Connector von Azure Data Factory für inkrementelles CDC. Testen Sie die Migration immer zunächst anhand einer nicht für die Produktion bestimmten Kopie, bevor Sie sie mit Produktivdaten ausführen.

Testen Sie Ihr Verständnis der Konzepte von Microsoft Azure Fundamentals (AZ-900) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Der Azure Database Migration Service orchestriert Online- und Offline-Datenbankmigrationen, die Vorabmigrationbewertung mit DMA erkennt Kompatibilitätsprobleme vor dem Migrationsfenster, und Change Data Capture ermöglicht einen Cutover von Produktionsdatenbanken mit nahezu null Ausfallzeit. Als Nächstes richten wir den Fokus auf die Optimierung der Azure-Kosten.