Migrationen mit verteilten Verfügbarkeitsgruppen (Distributed Availability Group, DAG)

Zusätzlich zum Standard-Migrationsablauf für Sicherung und Wiederherstellung in Cloud Storage unterstützt Database Migration Service die Migration selbstverwalteter SQL Server-Datenbanken zu Cloud SQL for SQL Server mithilfe von verteilten SQL Server-Verfügbarkeitsgruppen (Distributed Availability Groups, DAG).

Anstatt Sicherungs- und Transaktionslogdateien in einen Cloud Storage-Bucket zu exportieren und hochzuladen, konfiguriert Database Migration Service eine verteilte Verfügbarkeitsgruppe zwischen Ihrer Quellverfügbarkeitsgruppe und einer verwalteten sekundären Verfügbarkeitsgruppe auf Ihrer Cloud SQL for SQL Server-Zielinstanz. Bei dieser Konfiguration werden sowohl die anfängliche vollständige Last als auch die laufenden Datenbankänderungen direkt über eine private Netzwerkverbindung gestreamt.

Auf dieser Seite werden die folgenden Themen behandelt:

Wann sollten DAG-Migrationen verwendet werden?

In der folgenden Tabelle werden Standardmigrationen für Sicherung und Wiederherstellung mit Migrationen mit verteilten Verfügbarkeitsgruppen (Distributed Availability Group, DAG) verglichen, um Ihnen bei der Auswahl des besten Ansatzes für Ihre Arbeitslast zu helfen:

Funktion oder Anforderung Standardmigrationen für Sicherung und Wiederherstellung (Anleitung für die Standardmigration) Migrationen von verteilten Verfügbarkeitsgruppen (DAG) (DAG-Migrationsanleitung)
Unterstützte Quellen Selbstverwalteter SQL Server, Amazon RDS und Cloud SQL for SQL Server. Selbstverwalteter SQL Server (Enterprise Edition) mit Always On-Verfügbarkeitsgruppen.
Mechanismus für die Datenverschiebung Vollsicherung (.bak), optionales differenzielles Backup (.diff) und Transaktionslog-Dateien (.trn), die in Cloud Storage bereitgestellt werden. Direktes Netzwerk-Streaming über einen SQL Server-Datenbankspiegelungsendpunkt (DBM) (keine Sicherungsdateien oder Cloud Storage-Buckets erforderlich).
Netzwerkverbindung Keine Verbindung zwischen Quelle und Ziel erforderlich. Bidirektionale private IP-Verbindung am SQL Server-Datenbankport (Standard: 1433) und am Datenbankspiegelungsport (Standard: 5022) erforderlich.
Zugriff auf die Zieldatenbank während der Migration Datenbanken bleiben bis zur Hochstufung im Modus RESTORING (für Abfragen nicht zugänglich). Datenbanken sind während der Phase der kontinuierlichen Replikation (CDC) im Lesemodus zugänglich.
Failback nach Hochstufung Nicht unterstützt (einseitige Hochstufung). Integrierte umgekehrte Replikation (FAILBACK-Phase) von Cloud SQL for SQL Server zurück zur SQL Server-Quellinstanz nach der Hochstufung, mit Unterstützung für Failback-Wechsel ohne Datenverlust.

Funktionsweise von DAG-Migrationen

Während einer DAG-Migration orchestriert Database Migration Service die Datenreplikation zwischen Ihrer Quellverfügbarkeitsgruppe und einer verwalteten sekundären Verfügbarkeitsgruppe auf Ihrer Cloud SQL for SQL Server-Zielinstanz.

Netzwerkkommunikationskanäle

Database Migration Service verwendet zwei private Netzwerkkommunikationskanäle zwischen Ihrer SQL Server-Quellinstanz und der Cloud SQL for SQL Server-Zielinstanz:

  1. SQL Server Linked Server (Datenbankport, Standard 1433): Database Migration Service verwendet einen verknüpften Server, der auf der Cloud SQL for SQL Server-Zielinstanz konfiguriert ist, um administrative und Orchestrierungsabfragen auf der SQL Server-Quellinstanz auszuführen.
  2. Endpunkt für die Datenbankspiegelung (DBM) (Standard: 5022): Die Quellverfügbarkeitsgruppe und die Zielverfügbarkeitsgruppe von Cloud SQL for SQL Server tauschen zertifikatauthentifizierte Daten für die erste vollständige Ladung und laufende Datenbankänderungen direkt über den Port DBM aus.

Phasen des Migrationslebenszyklus

Ein DAG-Migrationsjob durchläuft vier Lebenszyklusphasen:

  1. Erste vollständige Last (FULL_DUMP): Wenn Sie den Migrationsjob starten, konfiguriert Database Migration Service die verteilte Verfügbarkeitsgruppe so, dass die erste vollständige Kopie aller Datenbanken in der Quellverfügbarkeitsgruppe über das Netzwerk an die Cloud SQL for SQL Server-Zielinstanz gestreamt wird.
  2. Kontinuierliche Replikation (CDC): Sobald die erste vollständige Ladung einer Datenbank abgeschlossen ist, wechselt sie in die Phase CDC. Laufende Änderungen an den Quelldatenbanken werden kontinuierlich über den DBM-Endpunkt repliziert. Sie können eine Verbindung zur Cloud SQL for SQL Server-Zielinstanz herstellen, um schreibgeschützte Bestätigungsabfragen für die replizierenden Datenbanken auszuführen.
  3. Hochstufung und umgekehrte Replikation (FAILBACK): Wenn Sie den Migrationsjob hochstufen (promote ohne das Flag --failback), synchronisiert Database Migration Service beide Verfügbarkeitsgruppen und vertauscht ihre Rollen, sodass die Cloud SQL for SQL Server-Zielinstanz zur primären Lese-/Schreibinstanz und Ihre ursprüngliche SQL Server-Quellinstanz zur sekundären Instanz wird. Außerdem wird die Phase des Migrationsjobs auf FAILBACK (PHASE_FAILBACK in der Google Cloud CLI und in API-Antworten) umgestellt. In der Phase FAILBACK bleibt der Migrationsjob im Status Running und repliziert neue Schreibvorgänge von Cloud SQL for SQL Server zurück in Ihre SQL Server-Quellinstanz.
  4. Failback-Switchover, ‑Beendigung oder ‑Abschluss (Stop und Delete):
    • Wenn Sie die Umstellung während der Phase FAILBACK rückgängig machen müssen, können Sie den Befehl promote mit dem Flag --failback (failback = true in der API) ausführen, um einen Failback-Wechsel ohne Datenverlust durchzuführen. Dadurch wird die ursprüngliche SQL Server-Quellinstanz als primäre Instanz wiederhergestellt, Cloud SQL for SQL Server wird wieder auf die sekundäre Instanz herabgestuft und der Migrationsjob wird in die Phase CDC zurückgesetzt.
    • Sie können stop ausführen, um die Datenreplikation für einen definierten, kurzen Zeitraum anzuhalten. Während die Replikation angehalten ist, werden weiterhin Aktualisierungen in den Transaktionslogs akkumuliert. Im Status Stopped können Sie entweder resume ausführen, um die Datenreplikation fortzusetzen, oder delete ausführen, um die Migration abzuschließen und die erforderliche Bereinigung durchzuführen.
    • Sobald Sie bestätigt haben, dass die Umstellung auf Cloud SQL for SQL Server dauerhaft ist, löschen (delete) Sie den Migrationsjob (entweder direkt oder aus dem Status Stopped). Durch das Löschen des Migrationsjobs wird die Migration abgeschlossen, die verteilte Verfügbarkeitsgruppe und die Zertifikate auf beiden Instanzen werden gelöscht und Sie können Cloud SQL for SQL Server-Features aktivieren, die während der Migration blockiert sind, z. B. die Wiederherstellung zu einem bestimmten Zeitpunkt und Lesereplikate.

Unterstützte Quell- und Zieldatenbanken

DAG-Migrationen unterstützen die folgenden Quell- und Zieldatenbankversionen:

  • Quelldatenbanken: Selbstverwalteter SQL Server Enterprise Edition (Versionen 2017, 2019, 2022 und 2025) mit aktiviertem Feature AlwaysOn-Verfügbarkeitsgruppen (unter Windows oder Linux).
  • Zieldatenbanken: Cloud SQL for SQL Server Enterprise Edition (Versionen 2017, 2019, 2022 und 2025).

Bekannte Einschränkungen für DAG-Migrationen

Beachten Sie die folgenden Einschränkungen, bevor Sie eine DAG-Migration konfigurieren:

  • Das Erstellen von DAG-Verbindungsprofilen und das Erstellen, Prüfen, Starten, Hochstufen oder Löschen von DAG-Migrationsjobs wird nur über die Google Cloud CLI oder die Database Migration Service API unterstützt. Sie können den Fortschritt des DAG-Migrationsjobs, den Status pro Datenbank und die Messwerte in der Google Cloud Console überwachen.
  • Sowohl die SQL Server-Quellinstanz als auch die Cloud SQL for SQL Server-Zielinstanz müssen die Enterprise Edition ausführen. Amazon RDS- und Cloud SQL for SQL Server-Quellen werden für DAG-Migrationen nicht unterstützt.
  • Mit jedem DAG-Migrationsjob werden alle Datenbanken migriert, die in einer einzelnen Quellverfügbarkeitsgruppe enthalten sind (bis zu 100 Datenbanken pro verteilter Verfügbarkeitsgruppe). Systemdatenbanken (master, model, msdb, tempdb) und die Hilfsdatenbank des Database Migration Service (gcp_dms_db) werden nicht migriert.
  • Alle Datenbanken in der Quellverfügbarkeitsgruppe müssen ihre Datendateien (.mdf und .ndf) im SQL Server-Standarddatenverzeichnis speichern.
  • Anforderungen an die Datenbankinhaberschaft:
    • Quelldatenbanken dürfen nicht dem sa-Anmeldenamen gehören. Ändern Sie vor dem Starten des Migrationsjobs den Datenbankinhaber von sa in einen anderen SQL-Anmeldenamen oder Windows-Nutzer.
    • Wenn eine Quelldatenbank einem Windows Active Directory-Nutzer gehört, müssen Sie entweder den Inhaber der Quelldatenbank vor der Migration in einen SQL-Anmeldenamen ändern oder Ihre Cloud SQL for SQL Server-Zielinstanz in Active Directory einbinden, damit Database Migration Service bei Beginn des Migrationsjobs automatisch den entsprechenden Windows-Anmeldenamen auf der Zielinstanz erstellen kann.
    • Für SQL-authentifizierte Datenbankinhaber erstellt Database Migration Service automatisch einen entsprechenden Login auf der Cloud SQL for SQL Server-Zielinstanz mit dem Präfix gcp_dms_, einer 6-stelligen Kennung und dem Namen des Quellinhabers (z. B. gcp_dms_a1b2c3_myowner), um die migrierte Datenbank zu besitzen.
  • Verbindungen über öffentliche IP-Adressen werden nicht unterstützt. Sie müssen eine private IP-Verbindung zwischen der SQL Server-Quellinstanz und der Cloud SQL for SQL Server-Zielinstanz über den Zugriff auf private Dienste oder Private Service Connect konfigurieren.
  • Einschränkungen für die Cloud SQL for SQL Server-Zielinstanz, während der DAG-Migrationsjob vorhanden ist: Ab dem Zeitpunkt, an dem Sie einen DAG-Migrationsjob starten, bis Sie den Migrationsjob löschen (einschließlich der Phase nach der Hochstufung FAILBACK):
    • Die Wiederherstellung zu einem bestimmten Zeitpunkt muss auf der Cloud SQL for SQL Server-Zielinstanz deaktiviert sein.
    • Lesereplikate und Lesepools werden auf der Cloud SQL for SQL Server-Zielinstanz nicht unterstützt.
    • Geplante Wartungen mit nahezu keinen Ausfallzeiten werden auf der Cloud SQL for SQL Server-Zielinstanz nicht unterstützt.
    • Ändern Sie das Datenbank-Flag cloud sql enable dag support auf der Cloud SQL for SQL Server-Zielinstanz nicht manuell. Database Migration Service aktiviert dieses Flag automatisch, wenn der Migrationsjob gestartet wird. Sie können es entfernen, nachdem Sie den Migrationsjob gelöscht haben.
  • Datenbanken während der Migration hinzufügen oder entfernen:
    • Sie können Datenbanken in Ihrer Quellverfügbarkeitsgruppe dynamisch hinzufügen oder entfernen, während sich der Migrationsjob in der Phase CDC befindet. Database Migration Service erkennt neu hinzugefügte Datenbanken automatisch, validiert sie und führt die erste vollständige Ladung in die Cloud SQL for SQL Server-Zielinstanz durch.
    • Wenn Sie eine Datenbank aus der Quellverfügbarkeitsgruppe entfernen, wird die Replikation für diese Datenbank beendet. Sie wird aus den verfolgten Objekten des Migrationsjobs entfernt und die Datenbank bleibt auf der Cloud SQL for SQL Server-Zielinstanz im Status RESTORING (sie wird nicht wiederhergestellt, wenn der Job hochgestuft wird).
    • Das Hinzufügen neuer Datenbanken direkt auf der Cloud SQL for SQL Server-Zielinstanz während der FAILBACK-Phase nach der Hochstufung wird nicht unterstützt. Die Zielverfügbarkeitsgruppe wird nicht mit neuen Datenbanken aktualisiert, die in Cloud SQL erstellt wurden.
  • Einschränkungen beim Beenden, Fortsetzen und Neustarten von DAG-Migrationsjobs:
    • Wenn Sie einen DAG-Migrationsjob beenden (stop), wird die Datenreplikation angehalten. Dadurch werden Aktualisierungen in den Transaktionslogs akkumuliert, während die Replikation angehalten ist. Beenden Sie einen DAG-Migrationsjob nur für einen definierten, kurzen Zeitraum, damit die Laufwerke für Transaktionslogs nicht voll werden. Im Status Stopped können Sie entweder resume ausführen, um die Datenreplikation fortzusetzen, oder delete, um die Migration abzuschließen und die erforderliche Bereinigung durchzuführen.
    • Wenn Sie einen fehlgeschlagenen oder beendeten DAG-Migrationsjob neu starten (restart), werden die migrierten Datenbanken auf der Cloud SQL for SQL Server-Zielinstanz gelöscht und der erste vollständige Ladevorgang (FULL_DUMP) wird über das Netzwerk noch einmal ausgeführt.

Nächste Schritte