Freigeben über

Ü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. LRS ist ein kostenloser Clouddienst, der für die von Azure SQL verwaltete Instanz verfügbar ist und auf der Protokollversandtechnologie von SQL Server basiert.

Hinweis

Sie können jetzt Ihre SQL Server-Instanz, die von Azure Arc aktiviert ist, direkt über das Azure-Portal zu azure SQL Managed Instance migrieren. Weitere Informationen finden Sie unter Migrieren zu azure SQL Managed Instance.

Da LRS standardmäßige SQL Server-Sicherungsdateien wiederhergestellt, können Sie sie verwenden, um von SQL Server zu migrieren, der von überall gehostet wird (entweder lokal oder in einer beliebigen Cloud) zu azure SQL Managed Instance.

Überprüfen Sie zum Starten der Migration mit LRS die Migration von Datenbanken von SQL Server 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. LRS ermöglicht zudem komplexe benutzerdefinierte Migrationen und Hybridarchitekturen zwischen lokalen SQL Server-Instanzen und SQL Managed Instance-Implementierungen.

Wenn Sie Azure Database Migration Service oder die Azure SQL-Erweiterung für die Migration nicht nutzen können, können Sie LRS (lokal redundanter Speicher) direkt mit PowerShell, Azure CLI-Cmdlets oder APIs verwenden, um Datenbankmigrationen zu einem SQL Managed Instance manuell zu erstellen und zu orchestrieren.

Erwägen Sie die Verwendung von LRS in den folgenden Fällen:

  • Sie benötigen eine bessere Kontrolle über Ihr Datenbankmigrationsprojekt.
  • Beim Cutover der Migration gibt es nur wenig Toleranz in Bezug auf Downtime.
  • Sie können die ausführbare Datei des Datenbankmigrationsdiensts nicht in Ihrer Umgebung installieren.
  • Für die ausführbare Datei von Database Migration Service besteht kein Zugriff auf Ihre Datenbanksicherungen.
  • Sie können die Azure SQL-Migrationserweiterung nicht in Ihrer Umgebung installieren, oder sie kann nicht auf Ihre Datenbanksicherungen zugreifen.
  • Sie haben keinen Zugriff auf das Hostbetriebssystem oder administratorrechte.
  • Sie können in Ihrer Umgebung keine Netzwerkports für Azure öffnen.
  • Netzwerkeinschränkungs- oder Proxyblockierungsprobleme sind in Ihrer Umgebung vorhanden.
  • Sicherungen werden über die Option TO URL direkt in Azure Blob Storage-Konten gespeichert.
  • Sie müssen differenzielle Sicherungen verwenden.

Da LRS durch Wiederherstellen standardmäßiger SQL Server-Sicherungsdateien funktioniert, unterstützt es Migrationen aus jeder Quelle. Die folgenden Quellen wurden getestet:

  • SQL Server vor Ort/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

  • LRS ist die einzige Methode zum Wiederherstellen differenzieller Sicherungen in SQL-verwalteten Instanzen. Es ist nicht möglich, differenzielle Sicherungen für verwaltete Instanzen manuell wiederherzustellen oder den NORECOVERY Modus mithilfe von T-SQL manuell festzulegen.

Funktionsweise von LRS

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. LRS unterstützt vollständige, protokollierte und differenzielle Sicherungen. Dann verwenden Sie den LRS-Cloud-Dienst, um Sicherungsdateien aus dem Azure Blob Storage-Speicherkonto in eine SQL Managed Instance wiederherzustellen. Das Blob Storage-Konto dient als Zwischenspeicher für Sicherungsdateien zwischen SQL Server und SQL Managed Instance.

LRS überwacht Ihr Blob Storage-Konto auf alle neuen Differenz- oder Protokollsicherungen, die Sie nach dem Wiederherstellen der vollständigen Sicherung hinzufügen. LRS stellt diese neuen Dateien dann automatisch wieder her. 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.

LRS erfordert keine bestimmte Namenskonvention für Sicherungsdateien. Der Dienst überprüft alle im Azure Blob Storage-Konto gespeicherten Daten und erstellt die Sicherungskette. Dabei werden nur die Dateiheader gelesen. Datenbanken befinden sich während des Migrationsprozesses im Zustand der Wiederherstellung. LRS stellt Datenbanken im NORECOVERY-Modus wieder her, sodass sie nicht für Lese- oder Schreibanforderungen verwendet werden können, bis der Migrationsprozess abgeschlossen ist.

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 LRS separat für jede Datenbank.
  • 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 mithilfe des Protokollwiedergabediensts.

Achtung

Das Erstellen von Sicherungen auf SQL Server mit aktiviertem CHECKSUM wird dringend empfohlen, da ein Risiko besteht, eine beschädigte Datenbank ohne diese Funktion auf Azure wiederherzustellen.

Vergleich der Migrationsmodi „AutoVervollständigen“ und „Kontinuierlich“

Sie können LRS entweder im Auto-Vervollständigungsmodus oder im kontinuierlichen Modus starten.

Verwenden Sie den AutoVervollständigen-Modus , wenn die gesamte Sicherungskette im Voraus generiert wurde, und wenn Sie nicht mehr planen, Dateien nach dem Start der Migration 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 beendet, wenn die letzte angegebene Sicherungsdatei wiederhergestellt wird. Die migrierte Datenbank steht für lese-/schreibzugriff auf sql Managed Instance zur Verfügung.

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 regelmäßig den Azure Blob Storage-Ordner und stellt alle neuen protokoll- oder differenziellen Sicherungsdateien wieder her, die gefunden werden.

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. Stellen Sie sicher, dass die letzte Sicherungsdatei wiederhergestellt wird, indem Sie überprüfen, ob das letzte Log-Tail-Backup 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 LRS beendet wurde, entweder automatisch durch Autovervollständigung oder manuell durch den Cutover-Vorgang, können Sie den Wiederherstellungsvorgang für eine Datenbank, die Sie auf einer SQL Managed Instance online gestellt haben, 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 Abbildung in diesem Abschnitt zeigt einen typischen Migrationsworkflow, während die Tabelle die Schritte umschreibt.

Verwenden Sie den AutoVervollständigen-Modus nur, wenn alle Sicherungskettendateien im Voraus verfügbar sind. Wir empfehlen diesen Modus bei passiven Workloads, für die keine Daten-Nachführung 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.

Diagramm, das die Schritte zur Log Replay Service-Orchestrierung für die verwaltete SQL-Instanz veranschaulicht.

Vorgang Einzelheiten
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. LRS erfordert keine bestimmte Namenskonvention für Dateien.

Wenn Sie mehrere Datenbanken migrieren, verwenden Sie für jede Datenbank einen separaten Ordner.
2. Starten von LRS in der Cloud Starten Sie den Dienst mit PowerShell (start-azsqlinstancedatabaselogreplay) oder der Azure CLI (az_sql_midb_log_replay_start cmdlets). Wählen Sie zwischen den Migrationsmodi „Automatisches Abschließen“ oder „Kontinuierlich“ aus.

Starten Sie LRS separat für jede Datenbank, die auf einen Sicherungsordner im Blob Storage-Konto verweist.

Sobald der Dienst gestartet wird, beginnt er damit, Sicherungen aus dem Blob Storage-Container in SQL Managed Instance wiederherzustellen.

Wenn Sie LRS im AutoVervollständigen-Modus starten, werden alle Sicherungen über die angegebene letzte Sicherungsdatei wiederhergestellt. Sie müssen alle Sicherungsdateien vorab hochladen, und Sie können keine neuen Sicherungsdateien hinzufügen, während die Migration ausgeführt wird. Dieser Modus wird für passive Workloads empfohlen, die keinen Datenabgleich erfordern.

Wenn Sie LRS im fortlaufenden Modus starten, stellt es alle Sicherungen wieder her, die Sie anfänglich hochgeladen haben, und überwacht dann alle neuen Dateien, die Sie in den Ordner hochladen. 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 Fortschritts des Vorgangs. Überwachen Sie den Fortschritt des laufenden Wiederherstellungsvorgangs mit PowerShell (get-azsqlinstancedatabaselogreplay) oder der Azure CLI (az_sql_midb_log_replay_show Cmdlets). 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 LRS für eine Datenbank nicht fortsetzen. Sie müssen den Migrationsprozess ganz neu starten.
3. Wechsel in die Cloud, wenn Sie bereit sind Wenn Sie LRS im AutoVervollständigen-Modus starten, wird die Migration automatisch beendet, nachdem die angegebene letzte Sicherungsdatei wiederhergestellt wurde.

Wenn Sie LRS im fortlaufenden Modus starten, beenden Sie die Anwendung und die Arbeitslast. 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 Log-Tail-Sicherung in der SQL-verwalteten Instanz wiederhergestellt wird. Beenden Sie den Cutover, indem Sie für LRS 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 LRS 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 bei der Dienstebene Unternehmenskritisch erheblich länger dauern, bis SQL Managed Instance 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 mehreren Terabyte größe migrieren, sollten Sie die folgenden Punkte berücksichtigen:

  • Ein einzelner LRS-Auftrag kann bis zu 30 Tage lang ausgeführt werden. Nach Ablauf dieses Zeitraums wird der Auftrag automatisch abgebrochen.
  • Bei lang andauernden Aufträgen können Systemupdates Migrationsaufträge unterbrechen und verlängern. Es wird dringend empfohlen, für geplante Systemupdates ein Wartungsfenster einzurichten. Planen Sie Ihre Migration um das geplante Wartungsfenster herum.
  • Migrationsaufträge, die durch Systemupdates unterbrochen werden, werden automatisch für SQL-verwaltete Instanzen mit General Purpose angehalten und fortgesetzt, während sie für SQL-verwaltete Instanzen mit Business Critical neu gestartet werden. 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.

Migration starten

Starten Sie die Migration, indem Sie LRS starten. Hierbei können Sie den Dienst entweder im Modus „AutoVervollständigen“ oder „Kontinuierlich“ starten. Ausführliche Informationen erhalten Sie unter "Migrieren von Datenbanken von SQL Server mithilfe des Protokollwiedergabediensts".

  • Modus zum automatischen Abschließen. Wenn Sie den AutoVervollständigen-Modus verwenden, wird die Migration automatisch beendet, wenn die letzten der angegebenen Sicherungsdateien wiederhergestellt werden. 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 Sie den manuellen Übergang angefordert haben.

    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.

    Der kontinuierliche Modus wird für aktive Workloads empfohlen, bei denen eine Aufholphase für die Daten erforderlich ist.

Planen Sie, einen einzelnen LRS-Migrationsauftrag innerhalb von maximal 30 Tagen abzuschließen. Nach Ablauf dieses Zeitraums wird der LRS-Auftrag automatisch abgebrochen.

Hinweis

Wenn Sie mehrere Datenbanken migrieren, muss sich jede Datenbank in einem eigenen Ordner befinden. Starten Sie LRS für jede Datenbank separat, indem Sie den vollständigen URI-Pfad des Azure Blob Storage-Containers und des jeweiligen Datenbankordners angeben. 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.

Verwandte Inhalte

  • Last updated on