Übersicht über den Protokollwiedergabedienst für Azure SQL Managed Instance
Gilt für: Azure SQL Managed Instance
Dieser Artikel bietet eine Übersicht über den Protokollwiedergabedienst (Log Replay Service, LRS), mit dem Sie Datenbanken von SQL Server zu Azure SQL Managed Instance migrieren können. Der Protokollwiedergabedienst ist ein kostenloser Clouddienst, der für Azure SQL Managed Instance verfügbar ist und auf der Protokollversandtechnologie von SQL Server basiert.
Da LRS Standard-SQL-Server-Sicherungsdateien wiederherstellt, können Sie es verwenden, um von SQL Server, der irgendwo gehostet wird (entweder vor Ort oder in einer beliebigen Cloud), zu Azure SQL Managed Instance zu migrieren.
Überprüfen Sie zum Starten der Migration mit LRS Migrieren von Datenbanken mithilfe des Protokollwiedergabediensts.
Wichtig
Bevor Sie Datenbanken zur Dienstebene Unternehmenskritisch migrieren, sollten Sie diese Einschränkungen, die nicht auf die Universelle Dienstebene angewendet werden, berücksichtigen.
Wann sollte der Protokollwiedergabedienst verwendet werden?
Azure Database Migration Service verwenden die Azure SQL-Migrationserweiterung für Azure Data Studio und LRS die gleiche zugrunde liegende Migrationstechnologie und die gleichen APIs. Der Protokollwiedergabedienst erweitert komplexe benutzerdefinierte Migrationen und Hybridarchitekturen zwischen lokalen SQL Server-Instanzen und SQL Managed Instance-Bereitstellungen.
Wenn die Verwendung von Azure Database Migration Service oder der Azure SQL-Erweiterung für die Migration nicht möglich ist, können Sie den lokal redundanten Speicher direkt mit PowerShell, Azure CLI-Cmdlets oder APIs nutzen, um Datenbankmigrationen zu SQL Managed Instance manuell zu erstellen und zu orchestrieren.
Erwägen Sie die Verwendung des Protokollwiedergabediensts in den folgenden Fällen:
- Sie benötigen eine bessere Kontrolle über Ihr Datenbankmigrationsprojekt.
- Es besteht nur eine geringe Toleranz in Bezug auf Ausfallzeiten während der Migrationsübernahme.
- Die ausführbare Datei von Database Migration Service kann in Ihrer Umgebung nicht installiert werden.
- Für die ausführbare Datei von Database Migration Service besteht kein Zugriff auf Ihre Datenbanksicherungen.
- Die Azure SQL-Migrationserweiterung kann nicht in Ihrer Umgebung installiert werden, oder sie kann nicht auf Ihre Datenbanksicherungen zugreifen.
- Es besteht kein Zugriff auf das Hostbetriebssystem, oder es sind keine Administratorrechte vorhanden.
- Sie können in Ihrer Umgebung keine Netzwerkports für Azure öffnen.
- In Ihrer Umgebung bestehen Probleme aufgrund von Netzwerkdrosselung oder Proxyblockierung.
- Sicherungen werden über die Option
TO URL
direkt in Azure Blob Storage-Konten gespeichert. - Sie müssen differenzielle Sicherungen verwenden.
Da LRS durch die Wiederherstellung von Standard-SQL-Server-Sicherungsdateien funktioniert, sollte es Migrationen aus jeder Quelle unterstützen. Die folgenden Quellen wurden getestet:
- SQL Server lokal/box
- SQL Server auf virtuellen Computern
- Amazon EC2 (Elastic Compute Cloud)
- Amazon RDS (Relational Database Service) für SQL Server
- Google Compute Engine
- Cloud SQL für SQL Server – GCP (Google Cloud Platform)
- Alibaba Cloud RDS für SQL Server
Wenn bei der Migration von einer nicht aufgelisteten Quelle unerwartete Probleme auftreten, öffnen Sie ein Supportticket, um Hilfe zu erhalten.
Hinweis
- Wir empfehlen Ihnen, die Migration von Datenbanken von SQL Server zu Azure SQL Managed Instance mithilfe der Azure SQL-Migrationserweiterung für Azure Data Studio zu automatisieren. Erwägen Sie die Verwendung des lokal rendundanten Speichers zum Orchestrieren von Migrationen, falls Ihre Szenarios der Azure SQL-Migrationserweiterung nicht vollständig unterstützt werden.
- Der Protokollwiedergabedienst ist die einzige Methode zum Wiederherstellen differenzieller Sicherungen in verwalteten Instanzen. Es ist nicht möglich, differenzielle Sicherungen in verwalteten Instanzen manuell wiederherzustellen oder den Modus
NORECOVERY
mithilfe von T-SQL manuell festzulegen.
Funktionsweise des Protokollwiedergabediensts
Für das Erstellen einer benutzerdefinierten Lösung zum Migrieren von Datenbanken in die Cloud mit dem Protokollwiedergabedienst sind einige Orchestrierungsschritte erforderlich. Diese sind weiter unten in diesem Abschnitt im Diagramm und der zugehörigen Tabelle dargestellt.
Die Migration umfasst das Erstellen von Datenbanksicherungen in SQL Server und das Kopieren von Sicherungsdateien in ein Azure Blob Storage-Konto. Vollständige, Protokoll- und differenzielle Sicherungen werden unterstützt. Dann verwenden Sie den Protokollwiedergabedienst in der Cloud, um Sicherungsdateien aus dem Azure Blob Storage-Konto in SQL Managed Instance wiederherzustellen. Das Blob Storage-Konto dient als Zwischenspeicher für Sicherungsdateien zwischen SQL Server und SQL Managed Instance.
Der Protokollwiedergabedienst überwacht Ihr Blob Storage-Konto auf neue differenzielle oder Protokollsicherungen, die nach der Wiederherstellung der vollständigen Sicherung hinzugefügt wurden. Diese neuen Dateien werden vom Protokollwiedergabedienst dann automatisch wiederhergestellt. Sie können den Dienst zum Überwachen des Status von Sicherungsdateien nutzen, die unter SQL Managed Instance wiederhergestellt werden, und den Prozess bei Bedarf anhalten.
Für den Protokollwiedergabedienst ist für Sicherungsdateien keine bestimmte Namenskonvention erforderlich. Der Dienst überprüft alle im Azure Blob Storage-Konto gespeicherten Daten und erstellt die Sicherungskette. Dabei werden nur die Dateiheader gelesen. Datenbanken weisen während des Migrationsprozesses den Zustand Wird wiederhergestellt auf. Die Datenbanken werden im Modus NORECOVERY wiederhergestellt und können daher erst nach Abschluss des Migrationsprozesses wieder für Lese- oder Schreibworkloads verwendet werden.
Beachten Sie Folgendes, wenn Sie mehrere Datenbanken migrieren:
- Speichern Sie Sicherungsdateien für jede Datenbank im Blob Storage-Konto in einem separaten Ordner in einer Flatfilestruktur. Verwenden Sie beispielsweise separate Datenbankordner: blobcontainer/datenbank1/dateien, blobcontainer/datenbank2/dateien usw.
- Verwenden Sie keine geschachtelten Ordner innerhalb der Datenbankordner, da eine Struktur mit geschachtelten Ordnern nicht unterstützt wird. Verwenden Sie keine Unterordner wie z. B. blobcontainer/datenbank1/unterordner/dateien.
- Starten Sie den Protokollwiedergabedienst für jede Datenbank separat.
- Geben Sie verschiedene URI-Pfade an, um die Datenbankordner im Blob Storage-Konto zu trennen.
Die Aktivierung von CHECKSUM
für Sicherungen ist zwar nicht erforderlich, wird aber dringend empfohlen. Die Wiederherstellung von Datenbanken ohne CHECKSUM
dauert länger, da SQL Managed Instance bei Sicherungen, die ohne Aktivierung von CHECKSUM
wiederhergestellt werden, eine Integritätsprüfung durchführt.
Weitere Informationen finden Sie unter Migrieren von Datenbanken aus SQL Server zu SQL Managed Instance mit dem Protokollwiedergabedienst.
Achtung
Das Erstellen von Sicherungen auf SQL Server mit aktivierter CHECKSUM
wird dringend empfohlen, da die Gefahr besteht, dass ohne sie eine beschädigte Datenbank in Azure wiederhergestellt wird.
Vergleich der Migrationsmodi „Automatisches Abschließen“ und „Kontinuierlich“
Sie können den Protokollwiedergabedienst entweder im Modus AutoVervollständigen oder Kontinuierlich starten.
Verwenden Sie den Modus Automatisches Abschließen, wenn Sie die gesamte Sicherungskette im Voraus generiert haben und nicht planen, nach dem Start der Migration weitere Dateien hinzuzufügen. Dieser Migrationsmodus wird für passive Workloads empfohlen, die keine Aufholphase für die Daten erfordern. Laden Sie alle Sicherungsdateien in das Blob Storage-Konto hoch, und starten Sie die Migration im Modus zum automatischen Abschließen. Die Migration wird automatisch abgeschlossen, wenn die letzte angegebene Sicherungsdatei wiederhergestellt wurde. Die migrierte Datenbank wird für den Lese-/Schreibzugriff auf der Instanz von SQL Managed Instance verfügbar.
Falls Sie planen, während der Ausführung der Migration immer wieder neue Sicherungen hinzuzufügen, verwenden Sie den Modus Kontinuierlich. Dieser Modus empfiehlt sich für aktive Workloads, bei denen eine Aufholphase für die Daten erforderlich ist. Laden Sie die aktuell verfügbare Sicherungskette in das Blob Storage-Konto hoch, starten Sie die Migration im kontinuierlichen Modus, und fügen Sie bei Bedarf immer wieder neue Sicherungsdateien aus Ihrer Workload hinzu. Das System überprüft den Azure Blob Storage-Ordner regelmäßig und stellt alle gefundenen neuen Dateien aus Protokoll- oder differenziellen Sicherungen wieder her.
Wenn Sie für den Cutover bereit sind, beenden Sie die Workload in Ihrer SQL Server-Instanz, generieren Sie die letzte Sicherungsdatei, und laden Sie diese dann hoch. Vergewissern Sie sich, dass die letzte Sicherungsdatei wiederhergestellt wurde, indem Sie überprüfen, ob die letzte Sicherung des Protokollendes in SQL Managed Instance als wiederhergestellt angezeigt wird. Initiieren Sie dann den manuellen Cutover. Mit dem abschließenden Übernahmeschritt wird die Datenbank online geschaltet und ist für den Lese-/Schreibzugriff in SQL Managed Instance verfügbar.
Nachdem der Protokollwiedergabedienst beendet wurde – entweder automatisch bei AutoVervollständigen oder manuell bei der Übernahme –, können Sie den Wiederherstellungsvorgang für eine Datenbank, die in SQL Managed Instance in den Onlinezustand versetzt wurde, nicht fortsetzen. Nach Abschluss der Migration können Sie beispielsweise keine weiteren differenziellen Sicherungen für eine Onlinedatenbank mehr wiederherstellen. Um nach Abschluss der Migration weitere Sicherungsdateien wiederherzustellen, müssen Sie die Datenbank in der verwalteten Instanz löschen und die Migration komplett neu starten.
Workflow bei der Migration
Die folgende Abbildung zeigt einen typischen Migrationsworkflow, die zugehörigen Schritte sind in der Tabelle aufgeführt.
Sie müssen den Modus zum automatischen Abschließen nur verwenden, wenn alle Sicherungskettendateien im Voraus verfügbar sind. Dieser Modus empfiehlt sich für passive Workloads, bei denen keine Aufholphase für die Daten erforderlich ist.
Verwenden Sie die Migration im kontinuierlichen Modus, wenn Sie nicht im Voraus über die gesamte Sicherungskette verfügen und wenn Sie planen, neue Sicherungsdateien hinzuzufügen, nachdem die Migration gestartet wurde. Dieser Modus empfiehlt sich für aktive Workloads, bei denen eine Aufholphase für die Daten erforderlich ist.
Vorgang | Details |
---|---|
1. Kopieren Sie Datenbanksicherungen aus der SQL Server-Instanz in das Blob Storage-Konto. | Kopieren Sie vollständige, differenzielle und Protokollsicherungen aus der SQL Server-Instanz mit AzCopy oder über den Azure Storage-Explorer in den Blob Storage-Container. Hierbei können Sie beliebige Dateinamen verwenden. Für den Protokollwiedergabedienst muss keine bestimmte Namenskonvention für Dateien befolgt werden. Wenn Sie mehrere Datenbanken migrieren, verwenden Sie für jede Datenbank einen separaten Ordner. |
2. Starten des Protokollwiedergabediensts in der Cloud | Sie können den Dienst mit dem PowerShell-Cmdlet start-azsqlinstancedatabaselogreplay oder mit dem Azure CLI-Cmdlet az_sql_midb_log_replay_start neu starten. Wählen Sie zwischen den Migrationsmodi „Automatisches Abschließen“ oder „Kontinuierlich“ aus. Starten Sie den Protokollwiedergabedienst separat für jede Datenbank, die auf einen Sicherungsordner im Blob Storage-Ordner verweist. Sobald der Dienst gestartet wird, beginnt er damit, Sicherungen aus dem Blob Storage-Container in SQL Managed Instance wiederherzustellen. Wenn der Protokollwiedergabedienst im Modus zum automatischen Abschließen gestartet wird, stellt er alle Sicherungen bis einschließlich der angegebenen letzten Sicherungsdatei wieder her. Alle Sicherungsdateien müssen im Voraus hochgeladen werden, und es ist nicht möglich, neue Sicherungsdateien hinzuzufügen, nachdem die Migration gestartet wurde. Dieser Modus wird für passive Workloads empfohlen, für die keine Aufholphase für die Daten erforderlich ist. Wenn der Protokollwiedergabedienst im kontinuierlichen Modus gestartet wird, stellt er alle anfangs hochgeladenen Sicherungen wieder her und wartet dann auf neue Dateien, die in den Ordner hochgeladen werden. Der Dienst wendet basierend auf der Kette mit Protokollfolgenummern (Log Sequence Number, LSN) fortlaufend Protokolle an, bis er manuell beendet wird. Dieser Modus empfiehlt sich für aktive Workloads, bei denen eine Aufholphase für die Daten erforderlich ist. |
2.1. Überwachen des Vorgangsstatus. | Sie können den Status des laufenden Wiederherstellungsvorgangs mit dem PowerShell-Cmdlet get-azsqlinstancedatabaselogreplay oder dem Azure CLI-Cmdlet az_sql_midb_log_replay_show überwachen. Um weitere Details zu einer fehlgeschlagenen Anforderung nachzuverfolgen, verwenden Sie den PowerShell-Befehl Get-AzSqlInstanceOperation oder den Azure CLI-Befehl az sql mi op show. |
2.2. Beenden des Vorgangs bei Bedarf (optional). | Falls Sie den Migrationsprozess beenden müssen, verwenden Sie das PowerShell-Cmdlet stop-azsqlinstancedatabaselogreplay oder das Azure CLI-Cmdlet az_sql_midb_log_replay_stop. Wenn Sie den Vorgang beenden, wird die Datenbank gelöscht, die Sie in SQL Managed Instance wiederherstellen. Nachdem Sie einen Vorgang beendet haben, können Sie den Protokollwiedergabedienst für eine Datenbank nicht fortsetzen. Sie müssen den Migrationsprozess ganz neu starten. |
3. Durchführen der Übernahme in die Cloud (bei entsprechender Bereitschaft) | Wenn der Protokollwiedergabedienst im Modus zum automatischen Abschließen gestartet wurde, wird die Migration automatisch beendet, nachdem die angegebene letzte Sicherungsdatei wiederhergestellt wurde. Wenn LRS im kontinuierlichen Modus gestartet wurde, beenden Sie die Anwendung und die Workload. Führen Sie die letzte Sicherung des Protokollendes aus, und laden Sie sie in die Azure Blob Storage-Bereitstellung hoch. Stellen Sie sicher, dass die letzte Sicherung des Protokollendes in der verwalteten Instanz wiederhergestellt wurde. Beenden Sie die Übernahme, indem Sie für den Protokollwiedergabedienst den Vorgang complete initiieren. Verwenden Sie hierzu das PowerShell-Cmdlet complete-azsqlinstancedatabaselogreplay oder das Azure CLI-Cmdlet az_sql_midb_log_replay_complete. Mit diesem Vorgang wird der Protokollwiedergabedienst beendet, wodurch die Datenbank in den Onlinezustand für Lese-/Schreibvorgänge in SQL Managed Instance versetzt wird. Ändern Sie die Anwendungsverbindungszeichenfolge so, dass sie nicht mehr auf die SQL Server-Instanz, sondern auf SQL Managed Instance zeigt. Sie müssen diesen Schritt selbst orchestrieren, entweder durch manuelle Änderung der Verbindungszeichenfolge in Ihrer Anwendung oder automatisch (wenn Ihre Anwendung beispielsweise die Verbindungszeichenfolge aus einer Eigenschaft oder einer Datenbank lesen kann). |
Wichtig
Nach dem Cutover kann es erheblich länger dauern bis SQL Managed Instance mit der Dienstebene Unternehmenskritisch wieder verfügbar ist als bei der Dienstebene Universell, da drei sekundäre Replikate für die Verfügbarkeitsgruppe übertragen werden müssen. Die Dauer des Vorgangs hängt von der Datenmenge ab. Weitere Informationen finden Sie unter Dauer von Verwaltungsvorgängen.
Migrieren großer Datenbanken
Wenn Sie große Datenbanken mit einer Größe von mehreren Terabyte migrieren, sollten Sie Folgendes beachten:
- Ein einzelner Auftrag des Protokollwiedergabediensts kann bis zu 30 Tage lang ausgeführt werden. Nach Ablauf dieses Zeitraums wird der Auftrag automatisch abgebrochen.
- Bei Aufträgen mit langer Ausführungsdauer werden Migrationsaufträge durch Systemupdates unterbrochen und verlängert. Es wird dringend empfohlen, für geplante Systemupdates ein Wartungsfenster einzurichten. Planen Sie Ihre Migration um das geplante Wartungsfenster herum.
- Durch Systemupdates unterbrochene Migrationsaufträge werden bei verwalteten Instanzen der Ebene Universell automatisch angehalten und wieder aufgenommen und bei verwalteten Instanzen der Ebene Unternehmenskritisch neu gestartet. Diese Updates wirken sich auf den Zeitrahmen Ihrer Migration aus.
- Um das Hochladen Ihrer SQL Server-Sicherungsdateien in das Blob Storage-Konto zu beschleunigen, erwägen Sie eine Parallelisierung mit mehreren Threads, sofern Ihre Infrastruktur über genügend Netzwerkbandbreite verfügt.
Starten der Migration
Sie starten die Migration, indem Sie den Protokollwiedergabedienst starten. Hierbei können Sie den Dienst entweder im Modus „AutoVervollständigen“ oder „Kontinuierlich“ starten. Ausführliche Informationen finden Sie unter Migrieren mit dem LRS.
Modus zum automatischen Abschließen. Bei Verwendung des Modus zum automatischen Abschließen wird der Migrationsprozess automatisch beendet, nachdem die letzte angegebene Sicherungsdatei wiederhergestellt wurde. Diese Option:
- Für diesen Modus muss die gesamte Sicherungskette im Voraus verfügbar sein und in das Azure Blob Storage-Konto hochgeladen worden sein.
- Das Hinzufügen neuer Sicherungsdateien während der Migration ist nicht möglich.
- In diesem Modus muss der Dateiname der letzten Sicherungsdatei im Startbefehl angegeben werden.
Der Modus zum automatischen Abschließen empfiehlt sich für passive Workloads, bei denen keine Aufholphase für die Daten erforderlich ist.
Fortlaufender Modus: Wenn Sie den kontinuierlichen Modus verwenden, überprüft der Dienst kontinuierlich den Azure Blob Storage-Ordner und stellt alle neuen Sicherungsdateien wieder her, die während der Migration hinzugefügt werden.
Die Migration wird erst abgeschlossen, nachdem der manuelle Cutover angefordert wurde.
Sie müssen die Migration im kontinuierlichen Modus verwenden, wenn Sie nicht im Voraus über die gesamte Sicherungskette verfügen und wenn Sie planen, neue Sicherungsdateien hinzuzufügen, nachdem die Migration gestartet wurde.
Der kontinuierliche Modus wird für aktive Workloads empfohlen, bei denen eine Aufholphase für die Daten erforderlich ist.
Planen Sie, einen einzelnen Migrationsauftrag des Protokollwiedergabediensts innerhalb von maximal 30 Tagen abzuschließen. Nach Ablauf dieses Zeitraums wird der Auftrag automatisch abgebrochen.
Hinweis
Wenn Sie mehrere Datenbanken migrieren, muss sich jede Datenbank in einem eigenen Ordner befinden. Der Protokollwiedergabedienst muss für jede Datenbank separat gestartet werden, die auf den vollständigen URI-Pfad des Azure Blob Storage-Containers und den jeweiligen Datenbankordner verweist. Geschachtelte Ordner in Datenbankordnern werden nicht unterstützt.
Einschränkungen von LRS
Informationen hierzu können Sie unter Einschränkungen bei der Verwendung von LRS finden.
Nächste Schritte
Weitere Informationen finden Sie unter Migrieren von Datenbanken aus SQL Server zu SQL Managed Instance mit dem Protokollwiedergabedienst.
Erfahren Sie mehr über das Migrieren von Datenbanken zu SQL Managed Instance mithilfe des Verbindungsfeatures.
Erfahren Sie mehr über das Migrieren von Datenbanken aus SQL Server zu SQL Managed Instance.
Erfahren Sie mehr über die Unterschiede zwischen SQL Server und SQL Managed Instance.
Erfahren Sie mehr über bewährte Methoden für Kostenermittlung und Größenanpassung von zu Azure migrierten Workloads.