Microsoft SQL Server zu STACKIT SQLServer Flex migrieren

Zweck und Umfang

Dieses Runbook beschreibt die Migration einer Microsoft-SQL-Server-Datenbank aus einer bestehenden Umgebung zu STACKIT SQLServer Flex. Wählen Sie einen von zwei Pfaden anhand der zulässigen Ausfallzeit und der Replikationsfähigkeit der Quellumgebung:

• S3-Backup-Restore: Geeignet für ein geplantes Migrationsfenster, in dem die Quelldatenbank für Backup und finale Validierung angehalten werden kann.
• Transaktionale Replikation: Geeignet, wenn die Quelldatenbank bis zu einem kurzen Cutover-Fenster verfügbar bleiben muss. Publisher und Distributor laufen in der Quellumgebung, SQLServer Flex ist der Subscriber.

Das Runbook behandelt die Migration von Datenbankdaten und Schema. Prüfen Sie Anwendungskompatibilität, SQL-Server-Agent-Jobs, Linked Servers, Credentials, externe Integrationen und Betriebsprozesse separat, bevor Sie den Cutover freigeben.

Rollen und Entscheidungspunkte

Benennen Sie diese Rollen vor der Migrationsprobe:

• Migrationsleitung: Verantwortet Zeitplan, Nachweise, Stakeholder-Kommunikation und die Go-/No-Go-Entscheidung.
• Quell-DBA: Verantwortet Backup-Konsistenz, Quellperformance, Publisher- und Distributor-Konfiguration sowie den Rollback der Quelle.
• Ziel-DBA: Verantwortet SQLServer-Flex-Provisionierung, Zugriffe, Import oder Subscription und die Zielvalidierung.
• Application Owner: Bestätigt die fachliche Abnahme und genehmigt Schreib-Freeze und Cutover.

Legen Sie eine maximale Ausfallzeit, einen Grenzwert für Replikationsverzug, einen Validierungsdatenbestand und einen Rollback-Zeitpunkt fest. Beginnen Sie den finalen Cutover nicht ohne schriftliche Einigung zu allen vier Punkten.

Migrationspfad wählen

Seitlich wischen, um die ganze Tabelle zu sehen

Kriterium	S3-Backup-Restore	Transaktionale Replikation
Geeignete Ausfallzeit	Geplantes Fenster für Backup, Import und Validierung	Kurzes finales Schreib-Freeze-Fenster
Initiale Datenübernahme	Vollständiges .bak-Backup in einem STACKIT-S3-Bucket	Wiederhergestelltes Backup oder gescriptetes Schema mit initialen Daten
Laufende Änderungen	Nach dem Backup nicht synchronisiert	Bis zum Cutover repliziert
Anforderungen an die Quelle	Konsistentes, unverschlüsseltes SQL-Server-Backup	SQL Server als Publisher und Distributor, SQL Server Agent, Primärschlüssel auf replizierten Tabellen
Zentral zu testendes Risiko	Restore-Dauer und Vollständigkeit des Backups	Replikationsverzug, Konnektivität sowie nicht unterstützte oder ausgelassene Objekte

Nutzen Sie den Backup-Restore, wenn Datenvolumen und Ausfallzeit getestet sind. Nutzen Sie transaktionale Replikation erst nach einem Ende-zu-Ende-Test außerhalb der Produktion; sie ist ein Migrationsmechanismus und ersetzt keine Kompatibilitätsprüfung auf Anwendungsebene.

Voraussetzungen

1. Legen Sie STACKIT-Projekt und SQLServer-Flex-Instanz an und bestätigen Sie Administratorzugriff sowie Zielendpunkt.
2. Stellen und testen Sie bei Replikation die Netzwerkverbindung vom quellseitigen Distributor zum SQLServer-Flex-Endpunkt.
3. Inventarisieren Sie Datenbanken, Schemas, Benutzer, SQL-Server-Agent-Jobs, Linked Servers, Zertifikate, Verschlüsselung, Abhängigkeiten und benötigte Wartungsaufgaben.
4. Definieren Sie Ziel-Datenbankname, Kollation, Kapazitätsbasis, Backup-Aufbewahrung, Monitoring und least-privilege Migrationskonten.
5. Führen Sie eine Probe mit repräsentativem Datenvolumen durch und dokumentieren Sie Dauer, Durchsatz, Fehler und Validierungsnachweise.
6. Planen Sie Change-Fenster, Schreib-Freeze auf der Quelle, Kommunikation und Rollback-Zeitpunkt.

Bereiten Sie für einen Backup-Restore einen STACKIT-S3-Bucket mit Zugangsdaten vor, über die der Restore die Backup-Dateien lesen kann. Der dokumentierte Import unterstützt nur unverschlüsselte Backups. Halten Sie Zugangsdaten aus Skripten, Tickets und Logs heraus.

Pfad A: S3-Backup-Restore

1. Backup vorbereiten und prüfen

1. Versetzen Sie die Quelldatenbank in den vereinbarten konsistenten Zustand und erstellen Sie ein vollständiges Backup.
2. Prüfen Sie, ob das Backup lesbar ist und Datenbankname, Größe sowie Abschlusszeit dem Migrationsplan entsprechen.
3. Stellen Sie sicher, dass das Backup unverschlüsselt ist und bei mehreren Dateien alle Teile verfügbar sind.
4. Laden Sie die .bak-Datei oder -Dateien in den vorbereiteten STACKIT-S3-Bucket und dokumentieren Sie die exakten S3-URIs.

2. In SQLServer Flex importieren

1. Bestätigen Sie, dass der Ziel-Datenbankname für den Import noch nicht verwendet wird.
2. Nutzen Sie die dokumentierte API oder die Stored Procedure [msdb].[stackit].[import_database] mit Zielname, S3-URI und S3-Zugangsdaten.
3. Warten Sie den asynchronen Restore ab; leiten Sie während des Imports keinen Anwendungstraffic auf das Ziel.
4. Dokumentieren Sie Restore-Request, Abschlusszeit und zurückgegebene Operations- oder Trace-IDs.

3. Validieren und umschalten

1. Vergleichen Sie Objektanzahl, Zeilenanzahl kritischer Tabellen und eine repräsentative Auswahl von Anwendungsabfragen mit der Quelle.
2. Erstellen oder validieren Sie Logins, Benutzer, Berechtigungen, Jobs und Anbindungsdaten, die im Zielentwurf enthalten sind.
3. Stoppen Sie Schreibvorgänge auf der Quelle, erstellen Sie bei Bedarf ein finales Backup und wiederholen Sie Import oder finale Synchronisation gemäß dem freigegebenen Ausfallplan.
4. Schalten Sie die Anwendung erst um, wenn der Application Owner die Validierungsnachweise akzeptiert hat.

Pfad B: Transaktionale Replikation

1. Zielbasis aufbauen

1. Erstellen Sie die Ziel-Datenbank in SQLServer Flex.
2. Initialisieren Sie diese möglichst mit einem wiederhergestellten Quell-Backup. Falls die Umgebungen keinen gemeinsamen Snapshot-Pfad erreichen können, skripten Sie die benötigten Objekte und laden die initialen Daten vor dem Anlegen der Subscription.
3. Erstellen Sie einen dedizierten Login und Datenbankbenutzer für die Verbindung von Distributor zu Subscriber. Vergeben Sie nur die Berechtigungen, welche das dokumentierte Replikationssetup benötigt.
4. Testen Sie die Verbindung vom quellseitigen Distributor zu SQLServer Flex mit den vorgesehenen Zugangsdaten.

2. Replikation auf der Quelle konfigurieren

1. Bestätigen Sie, dass jede für die Replikation vorgesehene Tabelle einen Primärschlüssel besitzt und SQL-Server-Edition sowie Versionen die gewählte Topologie unterstützen.
2. Konfigurieren Sie Distributor und Distribution-Datenbank in der Quellumgebung und registrieren Sie anschließend die Quelle als Publisher.
3. Aktivieren Sie die Quelldatenbank für Publishing, erstellen Sie eine transaktionale Publication und fügen Sie nur die freigegebenen Articles hinzu.
4. Konfigurieren Sie SQLServer Flex als Push-Subscriber mit replication support only, wenn das Ziel separat initialisiert wurde.
5. Starten Sie die Agents und prüfen Sie, dass Inserts, Updates und Deletes den Subscriber fehlerfrei erreichen.

3. Überwachen, validieren und umschalten

1. Überwachen Sie während der Synchronisationsphase Agent Health, Replikationslatenz, undistributed commands und das Wachstum des Quell-Transaction-Logs.
2. Gleichen Sie Zeilenanzahlen und kritische fachliche Summen ab, während die Replikation läuft. Untersuchen Sie jede Abweichung vor dem Cutover.
3. Stoppen Sie im freigegebenen Fenster Anwendungsschreibvorgänge auf der Quelle und warten Sie, bis der Replikationsverzug den vereinbarten Grenzwert erreicht, normalerweise null nicht verteilte Änderungen.
4. Führen Sie funktionale Smoke-Tests gegen SQLServer Flex aus, schalten Sie die Anbindung der Anwendung um und überwachen Sie das Ziel in der Stabilisierungsphase weiter.

Validierung und Rollback

Seitlich wischen, um die ganze Tabelle zu sehen

Checkpoint	Pass-Kriterium	Nachweis
Restore oder initiale Übernahme	Ziel-Datenbank ist online und enthält erwartetes Schema sowie Datenbasis	Import-Abschlussprotokoll oder Initialisierungslog
Datenintegrität	Vereinbarte Zeilenanzahlen, Summen und Stichproben-Abfragen stimmen überein	Signierter Validierungsbericht
Replikation, falls genutzt	Agents sind fehlerfrei und finaler Verzug liegt im vereinbarten Grenzwert	Agent-Historie und Lag-Messung
Anwendungsabnahme	Kritische Lese- und Schreibabläufe bestehen auf dem Ziel	Freigabe durch Application Owner
Betriebsbereitschaft	Monitoring, Zugriffe, Backups und Incident-Ownership sind aktiv	Day-1-Handover-Checkliste

Brechen Sie den Cutover ab und leiten Sie Anwendungstraffic zurück auf die Quelle, wenn eine kritische Validierung fehlschlägt, der Replikationsrückstand nicht innerhalb des genehmigten Fensters abgebaut werden kann oder die Zielperformance die vereinbarten Service Levels verhindert. Bewahren Sie Logs und Nachweise auf, analysieren Sie die Ursache und wiederholen Sie den Versuch erst nach einer neuen Go-/No-Go-Entscheidung.

Day-1-Betrieb

Überwachen Sie in der Stabilisierungsphase Verbindungsfehler, Datenbankperformance, fehlgeschlagene Jobs, Replikationsstatus bis zu dessen Stilllegung und Anwendungsfehlerraten. Halten Sie die Quelldatenbank für den vereinbarten Fallback-Zeitraum schreibgeschützt vor und bauen Sie danach Replikation, Quellzugriff und temporäre Migrationszugangsdaten über den freigegebenen Change-Prozess zurück.

Produktdokumentation

STACKIT Dokumentation docs.stackit.cloud Datenbanken aus einem STACKIT-S3-Bucket importieren Dokumentation öffnen STACKIT Dokumentation docs.stackit.cloud Transaktionale Replikation zu STACKIT implementieren Dokumentation öffnen