Verwenden von Log Replay Service (LRS) zum Migrieren
Log Replay Service (LRS) ist ein Tool, das benutzerdefinierte Migrationen von Datenbanken von lokalen SQL-Servern zu SQL Managed Instance in der Cloud ermöglicht. Es verwendet Protokollversandtechnologie und ist nützlich in Fällen, in denen mehr Kontrolle erforderlich ist, wenn es wenig Toleranz für Ausfallzeiten gibt oder wenn Azure Data Migration Service nicht verwendet werden kann.
LRS kann direkt mit PowerShell, CLI-Cmdlets oder API verwendet werden, um Datenbankmigrationen manuell zu SQL Managed Instance zu erstellen und zu koordinieren. Einige Gründe für die Verwendung von LRS sind:
- Mehr Kontrolle über das Datenbankmigrationsprojekt
- Geringe Toleranz für Ausfallzeiten bei Migrations-Cutover
- Unfähigkeit, ausführbare DMS-Dateien in der Umgebung zu installieren
- Fehlender Dateizugriff auf Datenbanksicherungen
- Unfähigkeit, Netzwerktechnologieports aus der Umgebung zu Azure zu öffnen
Grundlegendes zu Migrationstypen
Es gibt zwei Migrationsmodi für LRS.
| Mode | Beschreibung | Empfohlen für | Verfügbarkeit der Sicherungskette |
|---|---|---|---|
| AutoVervollständigen | Beendet die Migration automatisch, wenn die letzte Sicherungsdatei wiederhergestellt wird | Passive Workloads | Die gesamte Sicherungskette muss im Voraus verfügbar sein |
| Fortlaufend | Sucht kontinuierlich nach neuen Sicherungsdateien und stellt sie wieder her, sodass Daten aufholen können | Aktive Workloads | Sicherungskette kann während der Migration hinzugefügt werden |
Planen Sie unabhängig vom Modus die Migration innerhalb von 30 Tagen, da der LRS-Auftrag nach diesem Zeitpunkt automatisch abgebrochen wird.
Sichern des Migrationsprozesses
Zum Ausführen von LRS müssen Sie über eine der folgenden rollenbasierten Azure-Zugriffssteuerungsrollen (RBAC) verfügen: Abonnementbesitzer, SQL Managed Instance Contributor oder eine benutzerdefinierte Rolle mit der Berechtigung Microsoft.Sql/managedInstances/databases/*.
Ein Azure Blob Storage-Konto ist erforderlich und fungiert als zwischengeschalteter Speicher für Sicherungsdateien zwischen Ihrer SQL Server-Instanz und Ihrer SQL Managed Instance. Um Azure Blob-Speicher mit einer Firewall zu verwenden, ist eine weitere Konfiguration erforderlich. Sie müssen das Subnetz der SQL Managed Instance zu den Firewallregeln des virtuellen Netzwerks des Speicherkontos mithilfe der MI-Subnetzdelegierung und des Speicherdienstendpunkts hinzufügen. Außerdem können Sie entweder ein SAS-Token oder eine verwaltete Identität verwenden, um auf Ihr Azure Blob Storage-Konto zuzugreifen, aber nicht beides.
Verbessern der Sicherungs- und Wiederherstellungsleistung
Sie können vollständige und differenzielle Sicherungen in mehrere Dateien aufteilen, anstatt eine einzelne Datei zu verwenden, um die Leistung der Sicherung und Wiederherstellung zu verbessern. Dies liegt daran, dass mehrere Dateien parallel gelesen oder geschrieben werden können, wodurch die Zeit reduziert wird, die zum Abschließen des Sicherungs- oder Wiederherstellungsvorgangs benötigt wird.
Außerdem kann die Aktivierung der Sicherungskomprimierung dazu beitragen, die Geschwindigkeiten der Netzwerkübertragung zu verbessern. Komprimierte Sicherungen sind in der Größe kleiner, was bedeutet, dass sie weniger Zeit in Anspruch nehmen, um über das Netzwerk übertragen zu werden. Dies kann besonders nützlich sein, wenn große Sicherungen an oder von Azure übertragen werden.
Es wird dringend empfohlen, CHECKSUM für Sicherungen zu aktivieren, obwohl dies nicht erforderlich ist. SQL Managed Instance führt eine Integritätsprüfung für Sicherungen ohne CHECKSUM durch, wodurch die Zeit zum Wiederherstellen der Datenbank erhöht werden kann. Durch aktivieren von CHECKSUM, können Sie die Wiederherstellungsvorgänge beschleunigen.