Von selbstverwaltetem SQL Server mit verteilten Verfügbarkeitsgruppen migrieren

In diesem Leitfaden wird beschrieben, wie Sie Datenbanken von einer selbstverwalteten SQL Server Enterprise Edition-Instanz über eine private Netzwerkverbindung zu Cloud SQL for SQL Server Enterprise Edition migrieren. Dazu verwenden Sie eine verteilte Verfügbarkeitsgruppe (Distributed Availability Group, DAG) in Database Migration Service.

Bei einer DAG-Migration streamt Database Migration Service sowohl die anfängliche vollständige Last (die FULL_DUMP-Phase) als auch die kontinuierliche Replikation des Transaktionslogs (die Change Data Capture-Phase, CDC) direkt über das Netzwerk zwischen Ihrer Quellverfügbarkeitsgruppe und Ihrer Cloud SQL for SQL Server-Zielverfügbarkeitsgruppe. Weitere Informationen zur Architektur, zu den Voraussetzungen und zu den Einschränkungen von DAG-Migrationen finden Sie unter Informationen zu Migrationen mit verteilten Verfügbarkeitsgruppen (Distributed Availability Group, DAG). Informationen zur Migration mithilfe von Sicherungsdateien, die in Cloud Storage gespeichert sind, finden Sie unter SQL Server-Datenbanken zu Cloud SQL for SQL Server migrieren.

Für eine Migration mit einer verteilten Verfügbarkeitsgruppe führen Sie die folgenden allgemeinen Aufgaben aus:

1. Erstellen und bereiten Sie Ihre Cloud SQL for SQL Server-Zielinstanz vor.
2. Bereiten Sie die SQL Server-Quellinstanz und die Verfügbarkeitsgruppe vor.
3. Stellen Sie eine bidirektionale private Netzwerkverbindung her und konfigurieren Sie einen verknüpften Server.
4. Verbindungsprofile erstellen und den Migrationsjob ausführen
5. Migration überwachen und prüfen
6. Stufen Sie die Migration hoch, führen Sie ein Failback durch oder schließen Sie die Migration ab.

Kosten

Für homogene Migrationen zu Cloud SQL wird Database Migration Service kostenlos angeboten. Es gelten jedoch die Standardpreise für Cloud SQL und das Netzwerk. Mit dem Preisrechner können Sie Ihre Nutzungskosten abschätzen.

Hinweis

1. Prüfen Sie, ob Ihre Quell- und Zieldatenbanken alle Voraussetzungen und Einschränkungen für Migrationen mit verteilten Verfügbarkeitsgruppen erfüllen. Dazu gehören die Ausführung der Enterprise Edition, das Speichern von Datendateien im Standarddatenverzeichnis und die Verwendung von sa als Datenbankinhaber. Weitere Informationen finden Sie unter Informationen zu Migrationen mit verteilten Verfügbarkeitsgruppen (Distributed Availability Group, DAG).
2. Wählen Sie die Region Google Cloud für die Migration aus. Database Migration Service ist ein vollständig regionales Produkt. Alle mit Ihrer Migration verbundenen Entitäten (Quell- und Zielverbindungsprofile, Migrationsjob und Zielinstanz von Cloud SQL for SQL Server) müssen sich in derselben Region befinden.
3. Wählen Sie in der Google Cloud Console auf der Seite für die Projektauswahl ein-Projekt aus oder erstellen Sie Google Cloud eines.

   Zur Projektauswahl

4. Aktivieren Sie die Database Migration Service, Compute Engine und Cloud SQL Admin APIs.

   APIs aktivieren

Erforderliche Rollen

Prüfen Sie, ob die folgenden IAM-Rollen in IhremGoogle Cloud -Projekt gewährt wurden:

• Nutzerkonto, das die Migration durchführt:
  • Database Migration Admin (roles/datamigration.admin)
  • Cloud SQL-Bearbeiter (roles/cloudsql.editor)
• Database Migration Service-Dienstkonto (service-<var>PROJECT_NUMBER</var>@gcp-sa-datamigration.):
  • Database Migration Service-Agent (roles/datamigration.serviceAgent)
  • Cloud SQL-Bearbeiter (roles/cloudsql.editor)
  • Cloud SQL Studio User (roles/cloudsql.studioUser)

Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff verwalten.

Cloud SQL for SQL Server-Zielinstanz erstellen und vorbereiten

In diesem Schritt erstellen Sie die Cloud SQL for SQL Server Enterprise Edition-Zielinstanz und aktivieren das für verknüpfte Server erforderliche Datenbank-Flag.

1. Erstellen Sie Ihre Cloud SQL for SQL Server-Zielinstanz. Eine ausführliche Anleitung zum Erstellen finden Sie unter Cloud SQL for SQL Server-Instanz erstellen. Ihre Instanz muss die folgenden Anforderungen für Migrationen von verteilten Verfügbarkeitsgruppen erfüllen:
   • Wählen Sie Enterprise Edition (Version 2017, 2019, 2022 oder 2025) aus.
   • Konfigurieren Sie das private Netzwerk so, dass es der geplanten Verbindung zwischen der SQL Server-Quellinstanz und der Cloud SQL for SQL Server-Zielinstanz entspricht. Aktivieren Sie den Zugriff auf private Dienste, wenn Sie Ihre Instanzen über Virtual Private Cloud-Peering verbinden möchten, oder verwenden Sie Private Service Connect, wenn Sie Ihre Instanzen über einen eingehenden Private Service Connect-Endpunkt und einen ausgehenden Private Service Connect-Netzwerkanhang verbinden möchten.

     Aktivieren Sie nicht sowohl den Zugriff auf private Dienste als auch Private Service Connect auf derselben Cloud SQL for SQL Server-Zielinstanz. Cloud SQL for SQL Server unterstützt keine verknüpften Server, wenn beide aktiviert sind. Ausführliche Informationen zur Netzwerkeinrichtung finden Sie unter Bidirektionale private Netzwerkverbindung herstellen.

   • Lassen Sie die Wiederherstellung zu einem bestimmten Zeitpunkt (PITR) deaktiviert und fügen Sie erst dann Lesereplikate hinzu, wenn Sie den DAG-Migrationsjob abgeschlossen und gelöscht haben.
   • Wenn eine Quelldatenbank einem Windows Active Directory-Login gehört, ändern Sie entweder den Inhaber der Quelldatenbank vor der Migration in ein SQL-Login oder fügen Sie die Cloud SQL for SQL Server-Zielinstanz zu Active Directory hinzu, damit der Database Migration Service beim Start des Migrationsjobs automatisch das entsprechende Windows-Login auf der Zielinstanz erstellen kann. Eine Anleitung finden Sie unter Managed Microsoft AD für Cloud SQL for SQL Server konfigurieren.
2. Aktivieren Sie das Datenbank-Flag cloudsql enable linked servers (auf on festgelegt) auf Ihrer Cloud SQL for SQL Server-Zielinstanz. Eine Anleitung zum Festlegen von Flags finden Sie unter Verknüpfte Server verwalten und Datenbank-Flags konfigurieren.

   Dieses Flag wird später in diesem Leitfaden benötigt, wenn Sie den verknüpften Server auf Ihrer Cloud SQL for SQL Server-Zielinstanz erstellen und prüfen.

SQL Server-Quellinstanz vorbereiten

In diesem Schritt aktivieren Sie Always On-Verfügbarkeitsgruppen auf Ihrer SQL Server-Quellinstanz, erstellen einen Endpunkt und ein Zertifikat für die Datenbankspiegelung, erstellen ein dediziertes SQL-Login für Database Migration Service und bereiten Ihre Quellverfügbarkeitsgruppe vor.

Always On-Verfügbarkeitsgruppen aktivieren

Prüfen Sie, ob die Funktion „Always On-Verfügbarkeitsgruppen“ auf Ihrer SQL Server-Quellinstanz aktiviert ist:

• Informationen zu Windows finden Sie in der Microsoft-Dokumentation unter Always On-Verfügbarkeitsgruppen aktivieren und deaktivieren.
• Informationen zu Linux finden Sie in der Microsoft-Dokumentation unter SQL Server Always On-Verfügbarkeitsgruppe für Hochverfügbarkeit unter Linux konfigurieren.

Endpunkt und Zertifikat für die Datenbankspiegelung erstellen

In SQL Server werden Daten und Transaktionslogs zwischen Instanzen über TCP-DATABASE_MIRRORING-Endpunkte (DBM) (Standardport 5022) gestreamt. Da Ihre selbstverwaltete SQL Server-Instanz und Ihre Cloud SQL for SQL Server-Zielinstanz eigenständige Instanzen sind, benötigen sie eine zertifikatbasierte gegenseitige Authentifizierung und AES-Verschlüsselung, um Vertrauen über den DBM-Endpunkt herzustellen.

Sie müssen nur ein Zertifikat erstellen und es an den DATABASE_MIRRORING-Endpunkt auf Ihrer SQL Server-Quellinstanz binden. Sie müssen Zertifikatsdateien nicht manuell exportieren oder Zertifikate auf Ihrer Cloud SQL for SQL Server-Zielinstanz erstellen:

• Wenn Sie den Migrationsjob starten, konfiguriert der Database Migration Service automatisch den Endpunkt und das Zertifikat DATABASE_MIRRORING auf Ihrer Cloud SQL for SQL Server-Zielinstanz und verwendet Ihren verknüpften Server, um die öffentlichen Schlüssel zwischen beiden Instanzen auszutauschen.
• Wenn Sie den Migrationsjob nach Abschluss der Umstellung löschen, entfernt Database Migration Service die importierten Zertifikate automatisch aus beiden Instanzen.

Wenn Ihre SQL Server-Quellinstanz noch keinen mit einem Zertifikat authentifizierten DATABASE_MIRRORING-Endpunkt hat, erstellen Sie einen:

1. Stellen Sie mit einem SQL-Client, z. B. dem Dienstprogramm sqlcmd, eine Verbindung zur Quellinstanz her.
2. Führen Sie die folgenden T-SQL-Befehle aus, um einen Datenbank-Masterschlüssel, ein Zertifikat und einen DATABASE_MIRRORING-Endpunkt zu erstellen, der auf den von Ihnen ausgewählten DBM-Port (Standard: 5022) lauscht:

   USE [master];
   GO
   
   IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
   BEGIN
       CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'MASTER_KEY_PASSWORD';
   END
   GO
   
   CREATE CERTIFICATE [SOURCE_CERT_NAME]
       WITH SUBJECT = 'AlwaysOn AG Certificate',
       EXPIRY_DATE = 'CERT_EXPIRY_DATE';
   GO
   
   CREATE ENDPOINT [HADR_ENDPOINT_NAME]
       STATE = STARTED
       AS TCP (LISTENER_PORT = SOURCE_DBM_PORT_NUMBER)
       FOR DATABASE_MIRRORING (
           ROLE = ALL,
           AUTHENTICATION = CERTIFICATE [SOURCE_CERT_NAME],
           ENCRYPTION = REQUIRED ALGORITHM AES
       );
   GO

   Ersetzen Sie Folgendes:

   • MASTER_KEY_PASSWORD durch ein Passwort zum Verschlüsseln des Datenbank-Masterschlüssels.
   • SOURCE_CERT_NAME durch einen Namen für das Zertifikat der Quelldatenbankspiegelung (z. B. dbmCertificate).
   • CERT_EXPIRY_DATE durch das Ablaufdatum des Zertifikats im Format YYYYMMDD.
   • HADR_ENDPOINT_NAME durch den Namen des Endpunkts für die Datenbankspiegelung.
   • SOURCE_DBM_PORT_NUMBER durch die TCP-Portnummer für den Traffic der Datenbankspiegelung (Standard: 5022).

Dedizierte Anmeldung und Berechtigungen für Database Migration Service erstellen

Database Migration Service stellt über den verknüpften Server eine Verbindung zu Ihrer SQL Server-Quellinstanz her. Dazu wird ein dedizierter SQL-Anmeldename verwendet, den Sie im Quellverbindungsprofil angeben. Sie können diese Anmeldung konfigurieren, indem Sie die Serverrolle sysadmin gewähren oder Berechtigungen nach dem Prinzip der geringsten Berechtigung mit der Hilfsdatenbank gcp_dms_db konfigurieren:

Rolle „sysadmin“ gewähren

Wenn Ihre Sicherheitsrichtlinie die Zuweisung der Serverrolle sysadmin für die Migrationsanmeldung zulässt, führen Sie die folgenden T-SQL-Befehle aus:

USE [master];
GO
CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER SERVER ROLE [sysadmin] ADD MEMBER [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GO

Ersetzen Sie Folgendes:

• SOURCE_USERNAME durch den SQL-Anmeldenamen, den Database Migration Service für die Verbindung mit Ihrer Quellinstanz verwendet (z. B. cloud_dms_login).
• SOURCE_PASSWORD durch das Passwort für die Anmeldung bei SOURCE_USERNAME.
• SOURCE_USER durch den Datenbanknutzernamen, der SOURCE_USERNAME zugeordnet ist (z. B. cloud_dms_user).
• HADR_ENDPOINT_NAME durch den Namen des Endpunkts für die Datenbankspiegelung (z. B. Hadr_endpoint).

Geringste Berechtigung (gcp_dms_db)

Wenn Ihre Sicherheitsrichtlinie die Gewährung von sysadmin für die Migrationsanmeldung verbietet, erstellen Sie die dedizierte Hilfsdatenbank gcp_dms_db (im Besitz von sa mit TRUSTWORTHY ON), erstellen Sie die drei gespeicherten Wrapper-Prozeduren von Database Migration Service und gewähren Sie Ihrer Migrationsanmeldung detaillierte Berechtigungen:

USE [master];
GO

CREATE DATABASE [gcp_dms_db];
GO

ALTER AUTHORIZATION ON DATABASE::[gcp_dms_db] TO [sa];
ALTER DATABASE [gcp_dms_db] SET TRUSTWORTHY ON;
GO

USE [gcp_dms_db];
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_commit_mode
    @dag_name NVARCHAR(128),
    @source_ag NVARCHAR(128),
    @dest_ag NVARCHAR(128),
    @commit_mode NVARCHAR(30)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    IF @commit_mode NOT IN ('SYNCHRONOUS_COMMIT', 'ASYNCHRONOUS_COMMIT')
    BEGIN
        RAISERROR('Invalid commit mode. Must be SYNCHRONOUS_COMMIT or ASYNCHRONOUS_COMMIT.', 16, 1);
        RETURN;
    END
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) +
               N' MODIFY AVAILABILITY GROUP ON ' +
               QUOTENAME(@source_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N'), ' +
               QUOTENAME(@dest_ag, '''') + N' WITH (AVAILABILITY_MODE = ' + @commit_mode + N');';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_set_dag_secondary
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' SET (ROLE = SECONDARY);';
    EXECUTE sp_executesql @sql;
END;
GO

CREATE OR ALTER PROCEDURE dbo.gcp_dms_failover_dag
    @dag_name NVARCHAR(128)
WITH EXECUTE AS 'dbo'
AS
BEGIN
    SET NOCOUNT ON;
    DECLARE @sql NVARCHAR(MAX);
    SET @sql = N'USE master; ALTER AVAILABILITY GROUP ' + QUOTENAME(@dag_name) + N' FORCE_FAILOVER_ALLOW_DATA_LOSS;';
    EXECUTE sp_executesql @sql;
END;
GO

USE [master];
GO

CREATE LOGIN [SOURCE_USERNAME] WITH PASSWORD = 'SOURCE_PASSWORD';
CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT VIEW SERVER STATE TO [SOURCE_USERNAME];
-- Note: Run GRANT VIEW SERVER PERFORMANCE STATE on SQL Server 2022 and later:
GRANT VIEW SERVER PERFORMANCE STATE TO [SOURCE_USERNAME];
GRANT VIEW ANY DEFINITION TO [SOURCE_USERNAME];
GRANT ALTER ANY AVAILABILITY GROUP TO [SOURCE_USERNAME];
GRANT CONNECT ON ENDPOINT::[HADR_ENDPOINT_NAME] TO [SOURCE_USERNAME];
GRANT CREATE CERTIFICATE TO [SOURCE_USER];
GO

USE [gcp_dms_db];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_commit_mode TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_set_dag_secondary TO [SOURCE_USER];
GRANT EXECUTE ON dbo.gcp_dms_failover_dag TO [SOURCE_USER];
GO

-- Repeat the following block for EACH user database in your source Availability Group:
USE [DATABASE_NAME];
GO

CREATE USER [SOURCE_USER] FOR LOGIN [SOURCE_USERNAME];
ALTER ROLE [db_backupoperator] ADD MEMBER [SOURCE_USER];
GO

Ersetzen Sie Folgendes:

• SOURCE_USERNAME durch den SQL-Anmeldenamen, den Database Migration Service für die Verbindung mit Ihrer Quellinstanz verwendet (z. B. cloud_dms_login).
• SOURCE_PASSWORD durch das Passwort für die Anmeldung bei SOURCE_USERNAME.
• SOURCE_USER durch den Datenbanknutzernamen, der SOURCE_USERNAME zugeordnet ist (z. B. cloud_dms_user).
• HADR_ENDPOINT_NAME durch den Namen des Endpunkts für die Datenbankspiegelung (z. B. Hadr_endpoint).
• DATABASE_NAME durch den Namen jeder Quelldatenbank in Ihrer Verfügbarkeitsgruppe. Das Gewähren von db_backupoperator für jede migrierte Datenbank ist für die Preflight-Überprüfung von Database Migration Service erforderlich und ermöglicht das Leeren von Transaktionslogs mit CHECKPOINT während der Hochstufung.

Quelldatenbanken und Verfügbarkeitsgruppe vorbereiten

Sie können Datenbanken aus einer vorhandenen Always On-Verfügbarkeitsgruppe migrieren oder eine neue eigenständige Verfügbarkeitsgruppe (CLUSTER_TYPE = NONE) erstellen. Prüfen Sie die folgenden Anforderungen, bevor Sie fortfahren:

• Jede Datenbank in der Verfügbarkeitsgruppe verwendet das Wiederherstellungsmodell FULL, gehört nicht zu sa und speichert ihre Datendateien (.mdf und .ndf) im Standarddatenverzeichnis.
• Wenn Sie eine vorhandene Verfügbarkeitsgruppe wiederverwenden, prüfen Sie, ob der Endpunkt für die Datenbankspiegelung auf Port 5022 (oder dem von Ihnen gewählten DBM-Port) konfiguriert ist, ob SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) auf dem Replikat aktiviert ist, damit sekundäre Datenbanken nach dem Wechsel der DAG-Rollen mit Standard-Verbindungsstrings lesbar bleiben, und ob Ihr Migrations-Login CONNECT ON ENDPOINT hat. Wenn Ihre Quellverfügbarkeitsgruppe mehrere Replikate und einen Verfügbarkeitsgruppen-Listener konfiguriert hat, verwenden Sie die Listener-IP-Adresse als <var>SOURCE_HOST_IP_ADDRESS</var>, wenn Sie den verknüpften Server und das Quellverbindungsprofil konfigurieren, damit die Migration fortgesetzt werden kann, wenn ein Failover in der Quellverfügbarkeitsgruppe auftritt.

Führen Sie die folgenden T-SQL-Befehle aus, um eine Datenbank vorzubereiten und eine neue eigenständige Verfügbarkeitsgruppe (CLUSTER_TYPE = NONE) zu erstellen:

USE [master];
GO

ALTER DATABASE [DATABASE_NAME] SET RECOVERY FULL;
GO

-- If the database is owned by 'sa', change the owner to another login:
ALTER AUTHORIZATION ON DATABASE::[DATABASE_NAME] TO [DB_OWNER_LOGIN];
GO

-- Initialize the local SQL Server transaction log chain for the Availability Group:
BACKUP DATABASE [DATABASE_NAME] TO DISK = 'NUL';
GO

CREATE AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] WITH (CLUSTER_TYPE = NONE)
    FOR REPLICA ON N'SOURCE_SERVER_NAME' WITH (
        ENDPOINT_URL = N'TCP://localhost:SOURCE_DBM_PORT_NUMBER',
        FAILOVER_MODE = MANUAL,
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        SEEDING_MODE = MANUAL,
        PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE),
        SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL)
    );
GO

ALTER AVAILABILITY GROUP [SOURCE_AVAILABILITY_GROUP_NAME] ADD DATABASE [DATABASE_NAME];
GO

Ersetzen Sie Folgendes:

• DATABASE_NAME durch den Namen der Datenbank, die in die Verfügbarkeitsgruppe aufgenommen werden soll.
• DB_OWNER_LOGIN durch ein Nicht-sa-Anmeldekonto, das die Datenbank besitzen soll.
• SOURCE_AVAILABILITY_GROUP_NAME durch den Namen Ihrer Quell-Verfügbarkeitsgruppe (z. B. source_ag).
• SOURCE_SERVER_NAME durch den Servernamen Ihrer SQL Server-Quellinstanz (entspricht dem von SELECT @@SERVERNAME zurückgegebenen Wert).
• SOURCE_DBM_PORT_NUMBER durch die TCP-Portnummer Ihres Datenbankspiegelungsendpunkts (Standard: 5022).

Hinweis: Das Ausführen von BACKUP DATABASE ... TO DISK = 'NUL' ist eine lokale SQL Server-Anforderung, um die Transaktionsprotokollkette der Datenbank nach dem Wechsel zum Wiederherstellungsmodell FULL zu initialisieren, bevor sie einer Verfügbarkeitsgruppe hinzugefügt wird. Mit diesem Befehl wird die lokale Logkette für die Verfügbarkeitsgruppe initialisiert. Es werden keine Sicherungsdateien erstellt oder hochgeladen. Wenn Sie den Migrationsjob starten, konfiguriert Database Migration Service die verteilte Verfügbarkeitsgruppe so, dass die anfängliche vollständige Last direkt über das Netzwerk gestreamt wird.

Bidirektionale private Netzwerkverbindung herstellen

Bei DAG-Migrationen kommuniziert der Database Migration Service über interne Google Cloud -APIs mit Ihrer Cloud SQL for SQL Server-Zielinstanz, führt Orchestrierungsabfragen auf Ihrer SQL Server-Quellinstanz über einen verknüpften Server auf der Cloud SQL for SQL Server-Zielinstanz aus und streamt Daten direkt zwischen den beiden Instanzen über ein privates Netzwerk. Für diese Migration müssen Sie eine bidirektionale private IP-Verbindung direkt zwischen Ihrem SQL Server-Quellhost und Ihrer Cloud SQL for SQL Server-Zielinstanz über Ihr Virtual Private Cloud-Netzwerk herstellen. Verbindungen über öffentliche IP-Adressen zwischen den Quell- und Zielinstanzen werden nicht unterstützt.

Erforderliche Ports und IP-Adressen

Ihre Netzwerkkonfiguration muss Traffic zwischen Ihrer SQL Server-Quellinstanz und Ihrer Cloud SQL for SQL Server-Zielinstanz über die folgenden beiden TCP-Ports zulassen:

Port	Richtung	Zweck
SQL Server-Datenbankport (Standard: 1433)	Von der Cloud SQL for SQL Server-Zielinstanz zur SQL Server-Quellinstanz	Wird vom verknüpften Server auf Ihrer Cloud SQL for SQL Server-Zielinstanz verwendet, um Preflight-Validierungs-, Zertifikatsaustausch- und DAG-Orchestrierungsabfragen auf Ihrer Quellinstanz auszuführen.
Port für die Datenbankspiegelung (DBM) (Standard: 5022)	Bidirektional zwischen der SQL Server-Quellinstanz und der Cloud SQL for SQL Server-Zielinstanz	Wird von den Quell- und Zielverfügbarkeitsgruppen verwendet, um die anfängliche vollständige Last während FULL_DUMP, laufende Datenbankänderungen während CDC und die umgekehrte Replikation während FAILBACK zu streamen.

Wenn Sie später in diesem Leitfaden Ihren verknüpften Server und Ihre Verbindungsprofile konfigurieren, geben Sie zwei private IP-Adressen an:

• SOURCE_HOST_IP_ADDRESS (wird im Parameter @datasrc des verknüpften Servers und im Flag --host des Quellverbindungsprofils verwendet) ist die private IP-Adresse Ihres SQL Server-Quellhosts (oder die IP-Adresse des Availability Group-Listeners, die bevorzugt wird, wenn sie für eine Quell-Availability Group mit mehreren Replikaten konfiguriert ist, damit die Migration fortgesetzt werden kann, wenn ein Failover in der Quell-Availability Group auftritt), die von Ihrer Cloud SQL for SQL Server-Zielinstanz aus erreichbar ist.
• DESTINATION_HOST_IP_ADDRESS (wird im Flag --host des Zielverbindungsprofils verwendet) ist die private IP-Adresse Ihrer Cloud SQL for SQL Server-Zielinstanz (oder die IP-Adresse des Private Service Connect-Endpunkts), die von Ihrem SQL Server-Quellhost aus erreichbar ist.

Methode für private Netzwerke konfigurieren

Schließen Sie die Netzwerkrouting-Konfiguration für die Netzwerkmethode (Zugriff auf private Dienste oder Private Service Connect) ab, die Sie auf Ihrer Cloud SQL for SQL Server-Zielinstanz aktiviert haben:

Zugriff auf private Dienste

Beim Zugriff auf private Dienste wird Ihr Virtual Private Cloud-Netzwerk mit dem von Google verwalteten Virtual Private Cloud-Netzwerk des Diensterstellers verbunden, in dem Ihre Cloud SQL for SQL Server-Zielinstanz gehostet wird:

1. Prüfen Sie, ob Ihr Virtual Private Cloud-Netzwerk einen zugewiesenen internen IPv4-Adressbereich und eine private Verbindung (Virtual Private Cloud-Peering zu servicenetworking-googleapis-com) für Ihre Cloud SQL for SQL Server-Zielinstanz hat. Eine Anleitung finden Sie unter Private IP-Adresse für Cloud SQL for SQL Server konfigurieren.
2. Konfigurieren Sie das Routing zu Ihrem SQL Server-Quellhost basierend darauf, wo er gehostet wird:
   • Wenn Ihre Quellinstanz auf einer virtuellen Compute Engine-Maschine im selben Virtual Private Cloud-Netzwerk ausgeführt wird, ist kein zusätzliches Routing erforderlich. Die virtuelle Maschine und die Cloud SQL for SQL Server-Instanz können die privaten IP-Adressen der jeweils anderen Instanz direkt über die Virtual Private Cloud-Peering-Verbindung erreichen.
   • Wenn Ihre Quellinstanz lokal, bei einem anderen Cloud-Anbieter oder in einem anderen Virtual Private Cloud-Netzwerk ausgeführt wird, führen Sie die folgenden Schritte aus, damit Routen über die transitive Peering-Grenze hinweg ausgetauscht werden:
     1. Verbinden Sie Ihr externes Netzwerk über Cloud VPN oder Cloud Interconnect mit Ihrem Virtual Private Cloud-Netzwerk. Eine Anleitung finden Sie unter Über eine externe Quelle auf eine Cloud SQL-Instanz zugreifen.
     2. Geben Sie in Cloud Router den zugewiesenen IP-Adressbereich von Cloud SQL for SQL Server für Ihr Quellnetzwerk an. Eine Anleitung finden Sie unter Benutzerdefinierte IP-Bereiche bewerben.
     3. Aktualisieren Sie die Peering-Verbindung servicenetworking-googleapis-com in Ihrem Virtual Private Cloud-Netzwerk, um Benutzerdefinierte Routen exportieren zu aktivieren, damit Ihre Cloud SQL for SQL Server-Instanz die Routen zu Ihrem Quellnetzwerk lernt. Eine Anleitung finden Sie unter Peering-Verbindung aktualisieren.
3. Notieren Sie die privaten IP-Adressen für Ihre Migration:
   • Verwenden Sie die interne IP-Adresse des SQL Server-Quellhosts als SOURCE_HOST_IP_ADDRESS.
   • Verwenden Sie die private IP-Adresse, die Ihrer Cloud SQL for SQL Server-Zielinstanz zugewiesen ist (auf der Seite Übersicht der Instanz angezeigt), als DESTINATION_HOST_IP_ADDRESS.

Private Service Connect

Wenn Sie Private Service Connect anstelle des Zugriffs auf private Dienste verwenden, müssen Sie sowohl einen eingehenden Private Service Connect-Endpunkt (damit Ihre Quellinstanz über Port 5022 eine Verbindung zu Cloud SQL for SQL Server herstellen kann) als auch eine ausgehende Private Service Connect-Schnittstelle konfigurieren (damit Cloud SQL for SQL Server über die Ports 1433 und 5022 Verbindungen zu verknüpften Servern und DAG-Verbindungen zu Ihrer Quellinstanz initiieren kann):

1. Prüfen Sie, ob für die Cloud SQL for SQL Server-Zielinstanz Private Service Connect aktiviert ist (ohne private IP-Adresse) und ob die zulässigen Nutzerprojekte angegeben sind. Eine Anleitung finden Sie unter Private Service Connect konfigurieren.
2. Wenn Sie eingehende Verbindungen von Ihrem SQL Server-Quellhost zu Ihrer Cloud SQL for SQL Server-Zielinstanz zulassen möchten, reservieren Sie eine interne IP-Adresse in Ihrem Virtual Private Cloud-Subnetz und erstellen Sie einen Private Service Connect-Endpunkt (Weiterleitungsregel), der auf den Dienstanhang Ihrer Cloud SQL for SQL Server-Instanz verweist. Eine Anleitung finden Sie unter Private Service Connect-Endpunkt erstellen.
3. Wenn Sie ausgehende Verbindungen von Ihrer Cloud SQL for SQL Server-Zielinstanz zu Ihrem SQL Server-Quellhost zulassen möchten (erforderlich für verknüpfte Server und ausgehende DAG-Verbindungen), erstellen Sie einen Virtual Private Cloud-Netzwerkanhang im Subnetz, der zum Quellhost weiterleiten kann, und konfigurieren Sie die ausgehende Private Service Connect-Verbindung auf Ihrer Cloud SQL for SQL Server-Zielinstanz. Eine Anleitung finden Sie unter Netzwerkanhänge erstellen und verwalten und Ausgehende Private Service Connect-Verbindungen konfigurieren.
4. Notieren Sie die privaten IP-Adressen für Ihre Migration:
   • Verwenden Sie die private IP-Adresse Ihres SQL Server-Quellhosts als SOURCE_HOST_IP_ADDRESS.
   • Verwenden Sie die interne IP-Adresse Ihres Private Service Connect-Endpunkts (Weiterleitungsregel) in Ihrem Virtual Private Cloud-Netzwerk als DESTINATION_HOST_IP_ADDRESS.

Virtual Private Cloud- und Quellhost-Firewallregeln konfigurieren

1. Erstellen Sie in Ihrem Virtual Private Cloud-Netzwerk Firewallregeln für eingehenden und ausgehenden Traffic, die TCP-Traffic zwischen der IP-Adresse Ihres SQL Server-Quellservers (SOURCE_HOST_IP_ADDRESS) und dem IP-Bereich Ihres Cloud SQL for SQL Server-Ziels (oder dem Private Service Connect-Endpunkt und dem Subnetz des Netzwerkanhangs) sowohl über den Datenbankport (Standard: 1433) als auch über den Port für die Datenbankspiegelung (Standard: 5022) zulassen. Weitere Informationen zum Erstellen von Firewallregeln finden Sie unter Firewallregeln erstellen.
2. Prüfen Sie auf dem SQL Server-Quellcomputer die folgenden Netzwerk- und Host-Firewall-Einstellungen:
   • TCP/IP ist im SQL Server-Konfigurationsmanager (oder mssql-conf unter Linux) aktiviert und die Instanz überwacht einen statischen TCP-Port (Standard: 1433).
   • Die Betriebssystem-Firewall (z. B. Windows Defender Firewall oder Linux iptables oder firewalld) lässt eingehende TCP-Verbindungen sowohl über Ihren Datenbankport (Standard 1433) als auch über Ihren Datenbankspiegelungsport (Standard 5022) und ausgehende TCP-Verbindungen zu DESTINATION_HOST_IP_ADDRESS über Port 5022 zu.

Erreichbarkeit mit Cloud SQL-Konnektivitätstests prüfen

Bevor Sie den verknüpften Server konfigurieren, empfehlen wir, drei Konnektivitätstests auf dem Tab Verbindungen > Konnektivitätstests Ihrer Cloud SQL for SQL Server-Instanz in der Google Cloud -Konsole auszuführen. Eine Anleitung zum Ausführen eines Konnektivitätstests finden Sie unter Konnektivitätstests verwalten:

1. Wenn Sie die ausgehende Verbindung des verknüpften Servers über Port 1433 testen möchten, legen Sie Quelle auf Aktuelle Cloud SQL-Instanz, Ziel auf SOURCE_HOST_IP_ADDRESS und Zielport auf 1433 (oder Ihren benutzerdefinierten Datenbankport) fest.
2. Wenn Sie die ausgehende Verbindung für die Datenbankspiegelung über Port 5022 testen möchten, legen Sie Quelle auf Aktuelle Cloud SQL-Instanz, Ziel auf SOURCE_HOST_IP_ADDRESS und Zielport auf 5022 (oder Ihren benutzerdefinierten DBM-Port) fest.
3. Wenn Sie die eingehende Verbindung für die Datenbankspiegelung über Port 5022 testen möchten, legen Sie die Quelle auf SOURCE_HOST_IP_ADDRESS, das Ziel auf Aktuelle Cloud SQL-Instanz (oder DESTINATION_HOST_IP_ADDRESS, wenn Sie Private Service Connect verwenden) und den Zielport auf 5022 (oder Ihren benutzerdefinierten DBM-Port) fest.

Verknüpften Server auf der Cloud SQL for SQL Server-Zielinstanz erstellen und prüfen

Nachdem die Netzwerkverbindung hergestellt wurde, stellen Sie eine Verbindung zur Cloud SQL for SQL Server-Zielinstanz her und erstellen Sie den verknüpften Server, der auf die SQL Server-Quellinstanz verweist:

1. Stellen Sie mit einem SQL-Client eine Verbindung zur Cloud SQL-Instanz her. Sie können die folgenden Methoden verwenden:
   • sqlcmd-Client. Mit dieser Methode können Sie eine Verbindung zur privaten IP-Adresse Ihrer Instanz herstellen. Möglicherweise müssen Sie dazu jedoch eine virtuelle Compute Engine-Maschine erstellen.
   • Befehl gcloud sql connect Dieser Befehl funktioniert nur für Cloud SQL-Instanzen, für die eine öffentliche IP-Adresse aktiviert ist.
2. Melden Sie sich als sqlserver-Nutzer an und führen Sie die folgenden T-SQL-Befehle für Ihre Cloud SQL for SQL Server-Zielversion aus, um einen verknüpften Server zu erstellen, der auf Ihre SQL Server-Quellinstanz verweist, @locallogin = N'sqlserver' dem Migrations-Anmeldenamen der Quelle zuzuordnen, rpc out zu aktivieren und die Verbindung mit OPENQUERY zu testen. Weitere Informationen zu den Optionen für verknüpfte Server in Cloud SQL finden Sie unter Verknüpfte Server verwalten.

   Cloud SQL for SQL Server 2017, 2019 und 2022

   USE [master];
   GO
   
   EXEC master.dbo.sp_addlinkedserver
       @server = N'LINKED_SERVER_NAME',
       @srvproduct = N'',
       @provider = N'SQLNCLI',
       @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER';
   GO
   
   EXEC master.dbo.sp_addlinkedsrvlogin
       @rmtsrvname = N'LINKED_SERVER_NAME',
       @useself = N'False',
       @locallogin = N'sqlserver',
       @rmtuser = N'SOURCE_USERNAME',
       @rmtpassword = N'SOURCE_PASSWORD';
   GO
   
   EXEC master.dbo.sp_serveroption
       @server = N'LINKED_SERVER_NAME',
       @optname = N'rpc out',
       @optvalue = N'TRUE';
   GO
   
   SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
   GO

   Cloud SQL for SQL Server 2025

   USE [master];
   GO
   
   EXEC master.dbo.sp_addlinkedserver
       @server = N'LINKED_SERVER_NAME',
       @srvproduct = N'',
       @provider = N'MSOLEDBSQL19',
       @datasrc = N'SOURCE_HOST_IP_ADDRESS,SOURCE_PORT_NUMBER',
       @provstr = N'Encrypt=Optional;TrustServerCertificate=Yes;Authentication=SqlPassword;UID=Placeholder;';
   GO
   
   EXEC master.dbo.sp_addlinkedsrvlogin
       @rmtsrvname = N'LINKED_SERVER_NAME',
       @useself = N'False',
       @locallogin = N'sqlserver',
       @rmtuser = N'SOURCE_USERNAME',
       @rmtpassword = N'SOURCE_PASSWORD';
   GO
   
   EXEC master.dbo.sp_serveroption
       @server = N'LINKED_SERVER_NAME',
       @optname = N'rpc out',
       @optvalue = N'TRUE';
   GO
   
   SELECT * FROM OPENQUERY([LINKED_SERVER_NAME], 'SELECT @@VERSION AS SourceServerVersion');
   GO

   Ersetzen Sie Folgendes:

   • LINKED_SERVER_NAME durch den Namen für Ihren verknüpften Server in Cloud SQL for SQL Server (z. B. source_sql_linked_server).
   • SOURCE_HOST_IP_ADDRESS durch die private IP-Adresse Ihrer SQL Server-Quellinstanz (oder die IP-Adresse des Availability Group-Listeners, wenn für eine Availability Group mit mehreren Replikaten konfiguriert).
   • SOURCE_PORT_NUMBER durch die Portnummer, über die die SQL Server-Datenbank-Engine der Quelle Verbindungen akzeptiert (Standard: 1433).
   • SOURCE_USERNAME durch den dedizierten SQL-Anmeldenamen, den Sie auf Ihrer Quellinstanz in Dedizierte Anmeldung und Berechtigungen für Database Migration Service erstellen erstellt haben.
   • SOURCE_PASSWORD durch das Passwort für die Anmeldung bei SOURCE_USERNAME.

Verbindungsprofile erstellen und Migrationsjob ausführen

Verwenden Sie die Google Cloud CLI, um die Quell- und Zielverbindungsprofile zu erstellen, den kontinuierlichen DAG-Migrationsjob zu erstellen, die Migrationskonfiguration zu prüfen und den Migrationsjob zu starten:

1. Quellverbindungsprofil erstellen
   Führen Sie den Befehl gcloud database-migration connection-profiles create sqlserver aus (zum Maximieren klicken):

   gcloud database-migration connection-profiles create sqlserver

   In diesem Beispiel wird das optionale Flag --no-async verwendet, damit alle Vorgänge synchron ausgeführt werden. Das bedeutet, dass die Ausführung einiger Befehle eine Weile dauern kann. Sie können das Flag --no-async überspringen, um Befehle asynchron auszuführen. In diesem Fall müssen Sie den Befehl gcloud database-migration operations describe verwenden, um zu prüfen, ob der Vorgang erfolgreich war.

   gcloud database-migration connection-profiles create sqlserver SOURCE_CONNECTION_PROFILE_ID \
       --no-async \
       --display-name=SOURCE_CONNECTION_PROFILE_NAME \
       --region=REGION \
       --role=SOURCE \
       --host=SOURCE_HOST_IP_ADDRESS \
       --port=SOURCE_PORT_NUMBER \
       --dbm-port=SOURCE_DBM_PORT_NUMBER \
       --username=SOURCE_USERNAME \
       --password=SOURCE_PASSWORD

   Ersetzen Sie Folgendes:

   • SOURCE_CONNECTION_PROFILE_ID durch eine maschinenlesbare Kennung für Ihr Quellverbindungsprofil (z. B. sqlserver-dag-source-profile).
   • SOURCE_CONNECTION_PROFILE_NAME durch einen menschenlesbaren Namen für Ihr Quellverbindungsprofil. Dieser Wert wird in Database Migration Service in der Google Cloud Console angezeigt.
   • REGION durch die Kennung der Region, in der Sie das Verbindungsprofil speichern möchten (z. B. us-central1).
   • SOURCE_HOST_IP_ADDRESS durch die private IP-Adresse Ihrer SQL Server-Quellinstanz (oder die IP-Adresse des Availability Group-Listeners, wenn für eine Availability Group mit mehreren Replikaten konfiguriert).
   • SOURCE_PORT_NUMBER durch die Portnummer, über die die SQL Server-Datenbank-Engine der Quelle Verbindungen akzeptiert (Standard: 1433).
   • SOURCE_DBM_PORT_NUMBER durch die TCP-Portnummer des Quell-Datenbankspiegelungsendpunkts (Standard: 5022).
   • SOURCE_USERNAME durch den dedizierten SQL-Anmeldenamen, den Sie auf Ihrer Quellinstanz unter Dedizierte Anmeldung und Berechtigungen für Database Migration Service erstellen erstellt haben.
   • SOURCE_PASSWORD durch das Passwort für die Anmeldung bei SOURCE_USERNAME.

2. Erstellen Sie das Zielverbindungsprofil.
   Führen Sie den Befehl gcloud database-migration connection-profiles create sqlserver aus (zum Maximieren klicken):

   gcloud database-migration connection-profiles create sqlserver

   In diesem Beispiel wird das optionale Flag --no-async verwendet, damit alle Vorgänge synchron ausgeführt werden. Das bedeutet, dass die Ausführung einiger Befehle eine Weile dauern kann. Sie können das Flag --no-async überspringen, um Befehle asynchron auszuführen. In diesem Fall müssen Sie den Befehl gcloud database-migration operations describe verwenden, um zu prüfen, ob der Vorgang erfolgreich war.

   gcloud database-migration connection-profiles create sqlserver DESTINATION_CONNECTION_PROFILE_ID \
       --no-async \
       --display-name=DESTINATION_CONNECTION_PROFILE_NAME \
       --region=REGION \
       --role=DESTINATION \
       --cloudsql-instance=CLOUDSQL_INSTANCE_ID \
       --host=DESTINATION_HOST_IP_ADDRESS \
       --port=DESTINATION_PORT_NUMBER \
       --dbm-port=DESTINATION_DBM_PORT_NUMBER \
       --username=sqlserver \
       --password=CLOUD_SQL_DB_USER_PASSWORD

   Ersetzen Sie Folgendes:

   • DESTINATION_CONNECTION_PROFILE_ID durch eine maschinenlesbare Kennung für Ihr Zielverbindungsprofil (z. B. sqlserver-dag-dest-profile).
   • DESTINATION_CONNECTION_PROFILE_NAME durch einen menschenlesbaren Namen für das Zielverbindungsprofil. Dieser Wert wird in Database Migration Service in der Google Cloud Console angezeigt.
   • REGION durch die Kennung der Region, in der Sie das Verbindungsprofil speichern möchten.
   • CLOUDSQL_INSTANCE_ID durch den Namen Ihrer Cloud SQL for SQL Server-Zielinstanz.
   • DESTINATION_HOST_IP_ADDRESS durch die private IP-Adresse Ihrer Cloud SQL for SQL Server-Zielinstanz (oder die IP-Adresse des Private Service Connect-Endpunkts), die von Ihrer SQL Server-Quellinstanz aus erreichbar ist.
   • DESTINATION_PORT_NUMBER durch die Datenbankportnummer Ihrer Cloud SQL for SQL Server-Zielinstanz (1433).
   • DESTINATION_DBM_PORT_NUMBER durch die Portnummer für die Datenbankspiegelung Ihrer Cloud SQL for SQL Server-Zielinstanz (5022).
   • CLOUD_SQL_DB_USER_PASSWORD durch das Passwort für den sqlserver-Nutzer auf Ihrer Cloud SQL for SQL Server-Zielinstanz (--username muss auf sqlserver festgelegt sein).

3. Erstellen Sie den kontinuierlichen DAG-Migrationsjob.
   Führen Sie den Befehl gcloud database-migration migration-jobs create aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs create

   In diesem Beispiel wird das optionale Flag --no-async verwendet, damit alle Vorgänge synchron ausgeführt werden. Das bedeutet, dass die Ausführung einiger Befehle eine Weile dauern kann. Sie können das Flag --no-async überspringen, um Befehle asynchron auszuführen. In diesem Fall müssen Sie den Befehl gcloud database-migration operations describe verwenden, um zu prüfen, ob der Vorgang erfolgreich war.

   gcloud database-migration migration-jobs create MIGRATION_JOB_ID \
       --no-async \
       --display-name=MIGRATION_JOB_NAME \
       --region=REGION \
       --type=CONTINUOUS \
       --source=SOURCE_CONNECTION_PROFILE_ID \
       --destination=DESTINATION_CONNECTION_PROFILE_ID \
       --sqlserver-dag-source-ag=SOURCE_AVAILABILITY_GROUP_NAME \
       --sqlserver-dag-linked-server=LINKED_SERVER_NAME

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch eine maschinenlesbare Kennung für Ihren Migrationsjob (z. B. sqlserver-dag-job).
   • MIGRATION_JOB_NAME durch einen menschenlesbaren Namen für den Migrationsjob. Dieser Wert wird in der Google Cloud Console angezeigt.
   • REGION durch die Kennung der Region, in der Sie den Migrationsjob erstellen möchten.
   • SOURCE_CONNECTION_PROFILE_ID durch die Kennung Ihres Quellverbindungsprofils.
   • DESTINATION_CONNECTION_PROFILE_ID durch die Kennung Ihres Zielverbindungsprofils.
   • SOURCE_AVAILABILITY_GROUP_NAME durch den Namen der Verfügbarkeitsgruppe auf Ihrer SQL Server-Quellinstanz.
   • LINKED_SERVER_NAME durch den Namen des verknüpften Servers, den Sie auf Ihrer Cloud SQL for SQL Server-Zielinstanz in Verknüpften Server auf der Cloud SQL for SQL Server-Zielinstanz erstellen und prüfen konfiguriert haben.

4. Prüfen Sie die Konfiguration des Migrationsjobs.
   Bevor Sie einen DAG-Migrationsjob starten, müssen Sie verify ausführen, um die bidirektionale Netzwerkverbindung, den RPC-Zugriff auf verknüpfte Server, die gcp_dms_db-Berechtigungen (bei Verwendung des Prinzips der geringsten Berechtigung), die Quelldatenbankinhaber (um sicherzustellen, dass keine Datenbank im Besitz von sa ist) und die Standardpfade für Datendateien zu prüfen. Führen Sie den Befehl gcloud database-migration migration-jobs verify aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs verify

   gcloud database-migration migration-jobs verify MIGRATION_JOB_ID \
       --region=REGION

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch die Kennung Ihres Migrationsjobs.
   • REGION durch die Kennung der Region, in der der Migrationsjob gespeichert ist.

   Sie können den Status des Überprüfungsvorgangs mit dem Befehl gcloud database-migration operations describe prüfen.

5. Starten Sie den Migrationsjob.
   Führen Sie nach erfolgreicher Überprüfung den Befehl gcloud database-migration migration-jobs start aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs start

   gcloud database-migration migration-jobs start MIGRATION_JOB_ID \
       --region=REGION

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch die Kennung Ihres Migrationsjobs.
   • REGION durch die Kennung der Region, in der der Migrationsjob gespeichert ist.
   Achtung: Wenn Sie den DAG-Migrationsjob starten, setzt Database Migration Service das Flag cloud sql enable dag support auf Ihrer Cloud SQL for SQL Server-Zielinstanz automatisch auf on. Ändern oder entfernen Sie das Flag cloud sql enable dag support nicht manuell.

Migration überwachen und prüfen

Während der DAG-Migrationsjob ausgeführt wird, können Sie den Fortschritt in der Google Cloud Console überwachen, Ihre Zieldatenbanken während CDC im Lesemodus abfragen und die aktive Replikation verwalten.

Fortschritt in der Google Cloud Console beobachten

Sie können einen laufenden DAG-Migrationsjob in der Google Cloud Console auf der Seite Details zum Migrationsjob überwachen, genau wie andere Database Migration Service-Migrationsjobs:

• In der Tabelle Datenbanken auf der Detailseite des Migrationsjobs finden Sie die Echtzeitphase (Full dump während des ersten vollständigen Ladens, CDC während der kontinuierlichen Replikation und alle Fehlermeldungen auf Datenbankebene) und die Wiederherstellungsverzögerung für jede Datenbank in Ihrer Verfügbarkeitsgruppe.
• Sehen Sie sich auf dem Tab Monitoring das Diagramm Wiederherstellungsverzögerung (datamigration.googleapis.com/migration_job/max_replica_sec_lag, das die Replikationsverzögerung der verteilten Verfügbarkeitsgruppe in Sekunden pro Datenbank meldet) an.

Weitere Informationen zum Monitoring von Messwerten und Jobstatus finden Sie unter Messwerte für Migrationsjobs und Statuscodes für Migrationsjobs.

Migrierte Datenbanken während des CDC im Lesemodus prüfen

Im Gegensatz zu Sicherungsmigrationen, bei denen Zieldatenbanken bis zur Hochstufung im Status RESTORING verbleiben, können Sie bei Migrationen mit verteilten Verfügbarkeitsgruppen Ihre Cloud SQL for SQL Server-Zieldatenbanken im Lesemodus abfragen, sobald sie in die Phase CDC eintreten.

Für jede Datenbank, die einem SQL-Anmeldenamen auf der Quellinstanz gehört, erstellt Database Migration Service automatisch einen Anmeldenamen 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). Wenn Sie die Datenbank vor der Hochstufung mit diesem Anmeldenamen abfragen möchten, stellen Sie als sqlserver eine Verbindung zu Ihrer Cloud SQL for SQL Server-Zielinstanz her, suchen Sie den generierten Anmeldenamen in sys.server_principals und setzen Sie das Passwort zurück:

SELECT name FROM sys.server_principals WHERE name LIKE 'gcp_dms_%';
GO
ALTER LOGIN [GENERATED_DMS_OWNER_LOGIN] WITH PASSWORD = 'NEW_OWNER_PASSWORD';
GO

Ersetzen Sie Folgendes:

• GENERATED_DMS_OWNER_LOGIN durch den generierten Anmeldenamen des Datenbankinhabers, der von der Abfrage zurückgegeben wurde.
• NEW_OWNER_PASSWORD durch ein neues Passwort für die Anmeldung.

Weitere Informationen zum Prüfen migrierter Objekte und Daten finden Sie unter Migration prüfen.

Aktiven DAG-Migrationsjob verwalten (optional)

Während der Migrationsjob in der Phase CDC ausgeführt wird, können Sie die folgenden Verwaltungsvorgänge ausführen:

• Fügen Sie Datenbanken in der Quellverfügbarkeitsgruppe auf der SQL Server-Quellinstanz hinzu oder entfernen Sie sie, indem Sie ALTER AVAILABILITY GROUP ... ADD DATABASE oder ALTER AVAILABILITY GROUP ... REMOVE DATABASE ausführen. Database Migration Service erkennt die Änderung im nächsten Abfragezyklus automatisch und aktualisiert die Cloud SQL for SQL Server-Zielinstanz.
• Halten Sie die Datenreplikation vorübergehend an, indem Sie gcloud database-migration migration-jobs stop ausführen. Das Beenden eines DAG-Migrationsjobs sollte nur für einen definierten, kurzen Zeitraum erfolgen, da sich während der Replikationsunterbrechung weiterhin Aktualisierungen in den Transaktionslogs ansammeln und die Transaktionslog-Laufwerke füllen können. Im Status „Beendet“ können Sie entweder gcloud database-migration migration-jobs resume ausführen, um die Datenreplikation fortzusetzen, oder gcloud database-migration migration-jobs delete ausführen, um die Migration abzuschließen und die erforderliche Bereinigung durchzuführen.
• Starten Sie einen fehlgeschlagenen Migrationsjob neu, indem Sie gcloud database-migration migration-jobs restart ausführen. Wenn Sie einen DAG-Migrationsjob neu starten, werden die migrierten Datenbanken auf Ihrer Cloud SQL for SQL Server-Zielinstanz gelöscht, die verteilte Verfügbarkeitsgruppe wird neu erstellt und die anfängliche vollständige Last wird über das Netzwerk noch einmal ausgeführt.

Migration hochstufen, Failback ausführen oder abschließen

Wenn Sie Ihre Anwendungen auf Cloud SQL for SQL Server umstellen möchten, stufen Sie den Migrationsjob hoch. Bei einer DAG-Migration wird durch das Hochstufen des Jobs Cloud SQL for SQL Server zur primären Lese-/Schreibinstanz und der Migrationsjob wechselt in die Phase FAILBACK (PHASE_FAILBACK in Google Cloud CLI- und API-Antworten) mit aktiver umgekehrter Replikation zurück zu Ihrer SQL Server-Quellinstanz:

1. Beenden Sie die Schreibvorgänge der Anwendung in Ihre SQL Server-Quelldatenbanken und prüfen Sie den Messwert Wiederherstellungsverzögerung in der Google Cloud -Konsole, um zu bestätigen, dass die Replikationsverzögerung null erreicht hat.

2. Stufen Sie den Migrationsjob hoch, um auf Cloud SQL umzustellen.
   Führen Sie den Befehl gcloud database-migration migration-jobs promote aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs promote

   gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
       --region=REGION

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch die Kennung Ihres Migrationsjobs.
   • REGION durch die Kennung der Region, in der der Migrationsjob gespeichert ist.

   Während der Hochstufung führt Database Migration Service die folgenden Aktionen aus:

   • Legt die verteilte Verfügbarkeitsgruppe auf synchronen Commit fest, gibt einen CHECKPOINT für alle Quelldatenbanken aus, wartet, bis alle Transaktionen ohne Datenverlust synchronisiert wurden, und kehrt die Rollen der Verfügbarkeitsgruppe um, sodass Ihre Cloud SQL for SQL Server-Zielinstanz zur primären Lese-/Schreibinstanz und Ihre ursprüngliche SQL Server-Quellinstanz zur sekundären Instanz wird.
   • Der Migrationsjob bleibt im Status Running und der Unterstatus wechselt zur FAILBACK-Phase (PHASE_FAILBACK in der Google Cloud CLI und in API-Antworten). Neue Schreibvorgänge werden kontinuierlich von der Cloud SQL for SQL Server-Zielinstanz zurück zur SQL Server-Quellinstanz repliziert.

   Nachdem das Hochstufen abgeschlossen ist, verbinden Sie Ihre Anwendungen mit der neuen Cloud SQL for SQL Server-Instanz.

3. (Optional) Failback zur SQL Server-Quellinstanz durchführen.
   Wenn nach dem Umstellen Ihrer Anwendungen auf Cloud SQL for SQL Server ein Problem auftritt, während sich der Migrationsjob in der Phase FAILBACK befindet, können Sie die Umstellung ohne Datenverlust rückgängig machen. Beenden Sie dazu die Schreibvorgänge der Anwendung in Cloud SQL for SQL Server und führen Sie den Befehl gcloud database-migration migration-jobs promote mit dem Flag --failback aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs promote --failback

   gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
       --region=REGION \
       --failback

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch die Kennung Ihres Migrationsjobs.
   • REGION durch die Kennung der Region, in der der Migrationsjob gespeichert ist.

   Wenn Sie promote mit dem Flag --failback während der Phase FAILBACK ausführen, werden alle in Cloud SQL for SQL Server geschriebenen Änderungen synchronisiert. Außerdem wird die Replikationsrichtung wieder umgekehrt, sodass die ursprüngliche SQL Server-Verfügbarkeitsgruppe zur primären Lese-/Schreibgruppe und Cloud SQL for SQL Server zur sekundären Gruppe wird. Der Migrationsjob wird dann in die Phase CDC zurückgesetzt. Beachten Sie, dass --failback nur gültig ist, wenn sich der Migrationsjob in der Phase FAILBACK befindet. Wenn Sie promote ohne --failback während der Phase FAILBACK ausführen (oder --failback während der Phase CDC übergeben), schlägt die Validierung mit dem Fehler FAILED_PRECONDITION fehl und der Migrationsjob wird weiterhin ausgeführt.

4. (Optional) Beenden Sie die Datenreplikation, bevor Sie den Migrationsjob löschen.
   Wenn Sie die Datenreplikation beenden möchten, bevor Sie den Migrationsjob endgültig löschen, führen Sie den Befehl gcloud database-migration migration-jobs stop aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs stop

   gcloud database-migration migration-jobs stop MIGRATION_JOB_ID \
       --region=REGION

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch die Kennung Ihres Migrationsjobs.
   • REGION durch die Kennung der Region, in der der Migrationsjob gespeichert ist.
   Achtung: Wenn Sie einen Migrationsjob beenden, wird die Datenreplikation angehalten. Dies sollte jedoch nur für einen definierten, kurzen Zeitraum erfolgen, da sich während des Anhaltens der Replikation weiterhin Aktualisierungen in den Transaktionslogs ansammeln. Im Status Stopped können Sie entweder gcloud database-migration migration-jobs resume ausführen, um die Datenreplikation fortzusetzen, oder im nächsten Schritt gcloud database-migration migration-jobs delete ausführen, um die Migration abzuschließen und die erforderliche Bereinigung durchzuführen.

5. Schließen Sie die Migration ab und löschen Sie den Migrationsjob.
   Nachdem Sie überprüft haben, ob Ihre Anwendungen mit der neuen Cloud SQL for SQL Server-Zielinstanz vollständig funktionieren und Sie keine umgekehrte Replikation zur SQL Server-Quellinstanz mehr benötigen, löschen Sie den Migrationsjob (entweder im Status Running oder Stopped), um die Migration abzuschließen und die erforderliche Bereinigung durchzuführen. Führen Sie den Befehl gcloud database-migration migration-jobs delete aus (zum Maximieren klicken):

   gcloud database-migration migration-jobs delete

   Dieser Befehl gibt eine interaktive Bestätigungsaufforderung zurück, die Sie beantworten müssen, um den Vorgang abzuschließen. Sie können die Bestätigungsaufforderung mit dem optionalen Flag --quiet überspringen.

   gcloud database-migration migration-jobs delete MIGRATION_JOB_ID \
       --region=REGION

   Ersetzen Sie Folgendes:

   • MIGRATION_JOB_ID durch die Kennung Ihres Migrationsjobs.
   • REGION durch die Kennung der Region, in der der Migrationsjob gespeichert ist.

   Durch das Löschen des Migrationsjobs wird die Migration abgeschlossen, alle aktiven umgekehrten Replikationen werden beendet, die Zertifikate für die verteilte Verfügbarkeitsgruppe und die Datenbankspiegelung werden auf beiden Instanzen gelöscht und Sie können Cloud SQL for SQL Server-Features aktivieren, die während der DAG-Replikation eingeschränkt sind (z. B. Wiederherstellung zu einem bestimmten Zeitpunkt oder Lesereplikate).

   Nachdem Sie den Migrationsjob gelöscht haben, können Sie optional das Datenbank-Flag cloud sql enable dag support auf Ihrer Cloud SQL for SQL Server-Zielinstanz deaktivieren oder entfernen, den verknüpften Server auf Ihrer Cloud SQL for SQL Server-Instanz (EXEC master.dbo.sp_dropserver @server = N'LINKED_SERVER_NAME', @droplogins = 'droplogins';) löschen und die Hilfsdatenbank gcp_dms_db und die Migrationsanmeldung auf Ihrer SQL Server-Quellinstanz entfernen.