Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Migrer depuis SQL Server autogéré à l'aide de groupes de disponibilité distribués

Ce guide vous explique comment migrer des bases de données d'une instance SQL Server Enterprise Edition autogérée vers Cloud SQL pour SQL Server Enterprise Edition via une connexion réseau privée à l'aide d'un groupe de disponibilité distribué (DAG) dans Database Migration Service.

Avec une migration DAG, Database Migration Service diffuse à la fois le chargement complet initial (appelé phase FULL_DUMP) et la réplication continue du journal des transactions (appelée phase de capture de données modifiées ou CDC) directement sur le réseau entre votre groupe de disponibilité source et votre groupe de disponibilité Cloud SQL pour SQL Server de destination. Pour en savoir plus sur l'architecture, les prérequis et les limites des migrations de DAG, consultez À propos des migrations de groupes de disponibilité distribués (DAG). Pour effectuer une migration à l'aide de fichiers de sauvegarde stockés dans Cloud Storage, consultez Migrer vos bases de données SQL Server vers Cloud SQL pour SQL Server.

Pour effectuer une migration de groupe de disponibilité distribué, vous devez effectuer les tâches de premier niveau suivantes :

Créez et préparez votre instance Cloud SQL pour SQL Server de destination.
Préparez votre instance SQL Server source et votre groupe de disponibilité.
Établissez une connectivité réseau privée bidirectionnelle et configurez un serveur associé.
Créez des profils de connexion et exécutez le job de migration.
Surveillez et vérifiez votre migration.
Promouvez, effectuez un failback ou terminez la migration.

Coûts

Pour les migrations homogènes vers Cloud SQL, Database Migration Service est proposé sans frais supplémentaires. Toutefois, les tarifs standards de Cloud SQL et du réseau s'appliquent. Pour estimer vos coûts d'utilisation, utilisez le simulateur de coût.

Avant de commencer

Vérifiez que vos bases de données source et de destination respectent toutes les conditions préalables et limites applicables aux migrations de groupes de disponibilité distribués (y compris l'exécution d'Enterprise Edition, le stockage des fichiers de données dans le répertoire de données par défaut et l'absence d'utilisation de sa en tant que propriétaire de la base de données). Consultez À propos des migrations de groupes de disponibilité distribués (DAG).
Choisissez la région Google Cloud pour votre migration. Database Migration Service est un produit entièrement régional. Toutes les entités liées à votre migration (profils de connexion source et de destination, job de migration et instance Cloud SQL pour SQL Server de destination) doivent résider dans la même région.
Dans la console Google Cloud , sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud .
Accéder au sélecteur de projet
Activez les API Database Migration Service, Compute Engine et Cloud SQL Admin.
Activer les API

Rôles requis

Assurez-vous que les rôles IAM suivants sont accordés dans votre projetGoogle Cloud :

Compte utilisateur qui effectue la migration :
- Administrateur de migration de bases de données (roles/datamigration.admin)
- Éditeur Cloud SQL (roles/cloudsql.editor)
Compte de service Database Migration Service (service-<var>PROJECT_NUMBER</var>@gcp-sa-datamigration.iam.gserviceaccount.com) :
- Agent de service Database Migration Service (roles/datamigration.serviceAgent)
- Éditeur Cloud SQL (roles/cloudsql.editor)
- Utilisateur Cloud SQL Studio (roles/cloudsql.studioUser)

Pour en savoir plus sur l'attribution de rôles, consultez la section Gérer les accès.

Créer et préparer votre instance Cloud SQL pour SQL Server de destination

Dans cette étape, vous allez créer votre instance Cloud SQL pour SQL Server Enterprise Edition de destination et activer l'indicateur de base de données requis pour les serveurs associés.

Créez votre instance Cloud SQL pour SQL Server de destination. Pour obtenir des instructions de création détaillées, consultez Créer une instance Cloud SQL pour SQL Server. Assurez-vous que votre instance répond aux exigences suivantes pour les migrations de groupes de disponibilité distribués :
- Sélectionnez Enterprise Edition (version 2017, 2019, 2022 ou 2025).
- Configurez la mise en réseau privée en fonction de la manière dont vous prévoyez de connecter votre instance SQL Server source et votre instance Cloud SQL pour SQL Server de destination. Activez l' accès aux services privés si vous prévoyez de connecter vos instances via l'appairage de réseaux cloud privés virtuels, ou utilisez Private Service Connect si vous prévoyez de connecter vos instances à l'aide d'un point de terminaison Private Service Connect entrant et d'un rattachement de réseau Private Service Connect sortant.
  N'activez pas à la fois l'accès aux services privés et Private Service Connect sur la même instance Cloud SQL pour SQL Server de destination. Cloud SQL pour SQL Server n'est pas compatible avec les serveurs associés lorsque les deux sont activés. Pour en savoir plus sur la configuration réseau, consultez Établir une connectivité réseau privée bidirectionnelle.
- Laissez l'option Récupération à un moment précis (PITR) désactivée et n'ajoutez pas d'instances dupliquées avec accès en lecture tant que vous n'avez pas terminé et supprimé le job de migration DAG.
- Si une base de données source appartient à un identifiant Windows Active Directory, remplacez le propriétaire de la base de données source par un identifiant SQL avant la migration, ou associez l'instance Cloud SQL pour SQL Server de destination à Active Directory afin que Database Migration Service puisse créer automatiquement l'identifiant Windows correspondant sur l'instance de destination au démarrage du job de migration. Pour obtenir des instructions, consultez Configurer Microsoft AD géré pour Cloud SQL pour SQL Server.
Activez l'indicateur de base de données cloudsql enable linked servers (défini sur on) sur votre instance Cloud SQL pour SQL Server de destination. Pour savoir comment définir des indicateurs, consultez Gérer les serveurs associés et Configurer des indicateurs de base de données.
Vous en aurez besoin plus tard dans ce guide, lorsque vous créerez et vérifierez le serveur lié sur votre instance Cloud SQL pour SQL Server de destination.

Préparer votre instance SQL Server source

Dans cette étape, vous allez activer les groupes de disponibilité Always On sur votre instance SQL Server source, créer un point de terminaison et un certificat de mise en miroir de base de données, créer un identifiant SQL dédié pour Database Migration Service et préparer votre groupe de disponibilité source.

Activer les groupes de disponibilité Always On

Assurez-vous que la fonctionnalité Groupes de disponibilité AlwaysOn est activée sur votre instance SQL Server source :

Pour Windows, consultez Activer et désactiver les groupes de disponibilité Always On dans la documentation Microsoft.
Pour Linux, consultez Configurer un groupe de disponibilité Always On SQL Server pour la haute disponibilité sous Linux dans la documentation Microsoft.

Créer le point de terminaison et le certificat de mise en miroir de la base de données

Dans SQL Server, les groupes de disponibilité distribués diffusent des données et des journaux de transactions entre les instances via des points de terminaison TCP DATABASE_MIRRORING (DBM) (port par défaut 5022). Étant donné que votre instance SQL Server autogérée et votre instance Cloud SQL pour SQL Server de destination sont des instances autonomes, elles nécessitent une authentification mutuelle basée sur un certificat et un chiffrement AES pour établir une relation de confiance sur le point de terminaison DBM.

Il vous suffit de créer un certificat et de le lier au point de terminaison DATABASE_MIRRORING sur votre instance SQL Server source. Vous n'avez pas besoin d'exporter manuellement des fichiers de certificat ni de créer des certificats sur votre instance Cloud SQL pour SQL Server de destination :

Lorsque vous lancez le job de migration, Database Migration Service configure automatiquement le point de terminaison et le certificat DATABASE_MIRRORING sur votre instance Cloud SQL pour SQL Server de destination, et utilise votre serveur associé pour échanger les clés publiques entre les deux instances.
Lorsque vous supprimez le job de migration après avoir effectué le basculement, Database Migration Service supprime automatiquement les certificats importés des deux instances.

Si votre instance SQL Server source ne dispose pas déjà d'un point de terminaison DATABASE_MIRRORING authentifié avec un certificat, créez-en un :

Connectez-vous à votre instance source avec un client SQL, par exemple l'utilitaire sqlcmd.
Exécutez les commandes T-SQL suivantes pour créer une clé principale de base de données, un certificat et un point de terminaison DATABASE_MIRRORING qui écoute sur le port DBM de votre choix (5022 par défaut) :
```
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
```
Remplacez les éléments suivants :
- MASTER_KEY_PASSWORD par un mot de passe pour chiffrer la clé principale de la base de données.
- SOURCE_CERT_NAME par le nom de votre certificat de mise en miroir de base de données source (par exemple, dbmCertificate).
- CERT_EXPIRY_DATE par la date d'expiration du certificat au format YYYYMMDD.
- HADR_ENDPOINT_NAME par le nom de votre point de terminaison de mise en miroir de base de données.
- SOURCE_DBM_PORT_NUMBER par le numéro de port TCP pour le trafic de mise en miroir de base de données (5022 par défaut).

Database Migration Service se connecte à votre instance SQL Server source via le serveur associé à l'aide d'un identifiant SQL dédié que vous fournissez dans le profil de connexion source. Vous pouvez configurer cette connexion en accordant le rôle de serveur sysadmin ou en configurant des autorisations de moindre privilège avec la base de données d'assistance gcp_dms_db :

Attribuer le rôle sysadmin

Si votre stratégie de sécurité permet d'accorder le rôle de serveur sysadmin à l'identifiant de migration, exécutez les commandes T-SQL suivantes :

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

Remplacez les éléments suivants :

SOURCE_USERNAME par le nom de connexion SQL que Database Migration Service utilise pour se connecter à votre instance source (par exemple, cloud_dms_login).
SOURCE_PASSWORD par le mot de passe de l'identifiant SOURCE_USERNAME.
SOURCE_USER par le nom d'utilisateur de la base de données mappé sur SOURCE_USERNAME (par exemple, cloud_dms_user).
HADR_ENDPOINT_NAME par le nom de votre point de terminaison de mise en miroir de base de données (par exemple, Hadr_endpoint).

Moindre privilège (gcp_dms_db)

Si votre stratégie de sécurité interdit d'accorder sysadmin à l'identifiant de migration, créez la base de données d'assistance gcp_dms_db dédiée (appartenant à sa avec TRUSTWORTHY ON), créez les trois procédures stockées de wrapper Database Migration Service et accordez des autorisations précises à votre identifiant de migration :

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

Remplacez les éléments suivants :

SOURCE_USERNAME par le nom de connexion SQL que Database Migration Service utilise pour se connecter à votre instance source (par exemple, cloud_dms_login).
SOURCE_PASSWORD par le mot de passe de l'identifiant SOURCE_USERNAME.
SOURCE_USER par le nom d'utilisateur de la base de données mappé sur SOURCE_USERNAME (par exemple, cloud_dms_user).
HADR_ENDPOINT_NAME par le nom de votre point de terminaison de mise en miroir de base de données (par exemple, Hadr_endpoint).
DATABASE_NAME par le nom de chaque base de données source de votre groupe de disponibilité. L'attribution de db_backupoperator sur chaque base de données migrée est requise par la vérification préliminaire de Database Migration Service et permet de vider les journaux de transactions avec CHECKPOINT lors de la promotion.

Préparer vos bases de données sources et votre groupe de disponibilité

Vous pouvez migrer des bases de données à partir d'un groupe de disponibilité Always On existant ou créer un groupe de disponibilité autonome (CLUSTER_TYPE = NONE). Avant de continuer, vérifiez les exigences suivantes :

Chaque base de données du groupe de disponibilité utilise le modèle de récupération FULL, n'est pas détenue par sa et stocke ses fichiers de données (.mdf et .ndf) dans le répertoire de données par défaut.
Si vous réutilisez un groupe de disponibilité existant, vérifiez que votre point de terminaison de mise en miroir de base de données est configuré sur le port 5022 (ou le port DBM de votre choix), que SECONDARY_ROLE (ALLOW_CONNECTIONS = ALL) est activé sur l'instance répliquée afin que les bases de données secondaires restent lisibles avec des chaînes de connexion standards après que la promotion a inversé les rôles DAG, et que votre identifiant de migration dispose de CONNECT ON ENDPOINT. Si votre groupe de disponibilité source comporte plusieurs instances répliquées et qu'un écouteur de groupe de disponibilité est configuré, utilisez l'adresse IP de l'écouteur comme <var>SOURCE_HOST_IP_ADDRESS</var> lors de la configuration de votre serveur associé et de votre profil de connexion source afin que la migration puisse reprendre en cas de basculement dans le groupe de disponibilité source.

Pour préparer une base de données et créer un groupe de disponibilité autonome (CLUSTER_TYPE = NONE), exécutez les commandes T-SQL suivantes :

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

Remplacez les éléments suivants :

DATABASE_NAME par le nom de la base de données à inclure dans votre groupe de disponibilité.
DB_OWNER_LOGIN par un identifiant non-sa pour posséder la base de données.
SOURCE_AVAILABILITY_GROUP_NAME par le nom de votre groupe de disponibilité source (par exemple, source_ag).
SOURCE_SERVER_NAME par le nom de serveur de votre instance SQL Server source (correspondant à la valeur renvoyée par SELECT @@SERVERNAME).
SOURCE_DBM_PORT_NUMBER par le numéro de port TCP de votre point de terminaison de mise en miroir de base de données (par défaut, 5022).

Établir une connectivité réseau privée bidirectionnelle

Pour les migrations DAG, Database Migration Service communique avec votre instance Cloud SQL pour SQL Server de destination via des API Google Cloud internes, exécute des requêtes d'orchestration sur votre instance SQL Server source via un serveur lié sur l'instance Cloud SQL pour SQL Server de destination, et diffuse les données directement entre les deux instances sur un réseau privé. Cette migration nécessite d'établir une connectivité IP privée bidirectionnelle directement entre votre hôte SQL Server source et votre instance Cloud SQL pour SQL Server de destination via votre réseau cloud privé virtuel. La connectivité IP publique entre les instances source et de destination n'est pas prise en charge.

Ports et adresses IP requis

Votre configuration réseau doit autoriser le trafic entre votre instance SQL Server source et votre instance Cloud SQL pour SQL Server de destination sur les deux ports TCP suivants :

Port	Direction	Objectif
Port de la base de données SQL Server (par défaut : `1433`)	De l'instance Cloud SQL pour SQL Server de destination à l'instance SQL Server source	Utilisé par le serveur associé sur votre instance Cloud SQL pour SQL Server de destination pour exécuter des requêtes de validation préalable, d'échange de certificats et d'orchestration de DAG sur votre instance source.
Port de mise en miroir de base de données (`DBM`) (par défaut : `5022`)	Bidirectionnel entre l'instance SQL Server source et l'instance Cloud SQL pour SQL Server de destination	Utilisé par les groupes de disponibilité source et de destination pour diffuser le chargement complet initial pendant `FULL_DUMP`, les modifications de base de données en cours pendant `CDC` et la réplication inverse pendant `FAILBACK`.

Lorsque vous configurerez votre serveur associé et vos profils de connexion plus loin dans ce guide, vous fournirez deux adresses IP privées :

SOURCE_HOST_IP_ADDRESS (utilisé dans le paramètre de serveur associé @datasrc et l'option de profil de connexion source --host) est l'adresse IP privée de votre hôte SQL Server source (ou l'adresse IP de l'écouteur du groupe de disponibilité, qui est préférable si elle est configurée pour un groupe de disponibilité source multi-instance répliquée afin que la migration puisse reprendre en cas de basculement dans le groupe de disponibilité source) accessible depuis votre instance Cloud SQL pour SQL Server de destination.
DESTINATION_HOST_IP_ADDRESS (utilisé dans l'option de profil de connexion de destination --host) est l'adresse IP privée de votre instance Cloud SQL pour SQL Server de destination (ou l'adresse IP de son point de terminaison Private Service Connect) accessible depuis votre hôte SQL Server source.

Configurer votre méthode de mise en réseau privée

Terminez la configuration du routage réseau pour la méthode de mise en réseau (accès aux services privés ou Private Service Connect) que vous avez activée sur votre instance Cloud SQL pour SQL Server de destination :

Accès aux services privés

L'accès aux services privés appaire votre réseau cloud privé virtuel au réseau cloud privé virtuel du producteur de services géré par Google qui héberge votre instance Cloud SQL pour SQL Server de destination :

Vérifiez que votre réseau cloud privé virtuel dispose d'une plage d'adresses IPv4 internes allouée et d'une connexion privée (appairage de cloud privé virtuel à servicenetworking-googleapis-com) activée pour votre instance Cloud SQL pour SQL Server de destination. Pour obtenir des instructions, consultez Configurer une adresse IP privée pour Cloud SQL pour SQL Server.
Configurez le routage vers votre hôte SQL Server source en fonction de l'emplacement où il est hébergé :
- Si votre instance source s'exécute sur une machine virtuelle Compute Engine du même réseau cloud privé virtuel, aucun routage supplémentaire n'est requis. La machine virtuelle et l'instance Cloud SQL pour SQL Server peuvent accéder directement à leurs adresses IP privées respectives via la connexion d'appairage de cloud privé virtuel.
- Si votre instance source s'exécute sur site, chez un autre fournisseur cloud ou dans un autre réseau cloud privé virtuel, procédez comme suit pour que les routes soient échangées au-delà de la limite d'appairage transitif :
  1. Connectez votre réseau externe à votre réseau cloud privé virtuel à l'aide de Cloud VPN ou de Cloud Interconnect. Pour obtenir des instructions, consultez Accéder à une instance Cloud SQL depuis une source externe.
  2. Dans Cloud Router, annoncez la plage d'adresses IP allouée à Cloud SQL pour SQL Server sur votre réseau source. Pour plus d'informations, consultez la section Annoncer des plages d'adresses IP personnalisées.
  3. Mettez à jour la connexion d'appairage servicenetworking-googleapis-com dans votre réseau cloud privé virtuel pour activer l'option Exporter les routes personnalisées afin que votre instance Cloud SQL pour SQL Server apprenne les routes vers votre réseau source. Pour obtenir des instructions, consultez Mettre à jour une connexion d'appairage.
Notez les adresses IP privées pour votre migration :
- Utilisez l'adresse IP interne de votre hôte SQL Server source comme SOURCE_HOST_IP_ADDRESS.
- Utilisez l'adresse IP privée attribuée à votre instance Cloud SQL pour SQL Server de destination (affichée sur la page Présentation de l'instance) comme DESTINATION_HOST_IP_ADDRESS.

Private Service Connect

Si vous utilisez Private Service Connect au lieu de l'accès aux services privés, vous devez configurer à la fois un point de terminaison Private Service Connect entrant (pour que votre instance source puisse se connecter à Cloud SQL pour SQL Server sur le port 5022) et une interface Private Service Connect sortante (pour que Cloud SQL pour SQL Server puisse initier des connexions de serveur associé et de DAG à votre instance source sur les ports 1433 et 5022) :

Vérifiez que Private Service Connect est activé sur votre instance Cloud SQL pour SQL Server de destination (sans adresse IP privée) et que vos projets clients autorisés sont spécifiés. Pour obtenir des instructions, consultez Configurer Private Service Connect.
Pour autoriser les connexions entrantes de votre hôte SQL Server source vers votre instance Cloud SQL pour SQL Server de destination, réservez une adresse IP interne dans votre sous-réseau de cloud privé virtuel et créez un point de terminaison Private Service Connect (règle de transfert) qui cible le rattachement de service de votre instance Cloud SQL pour SQL Server. Pour obtenir des instructions, consultez Créer un point de terminaison Private Service Connect.
Pour autoriser les connexions sortantes de votre instance Cloud SQL pour SQL Server de destination vers votre hôte SQL Server source (requis pour les connexions de serveur associé et de DAG sortant), créez un rattachement de réseau de cloud privé virtuel dans le sous-réseau qui peut acheminer vers votre hôte source et configurez la connectivité sortante Private Service Connect sur votre instance Cloud SQL pour SQL Server de destination. Pour obtenir des instructions, consultez Créer et gérer des rattachements de réseau et Configurer la connectivité sortante Private Service Connect.
Notez les adresses IP privées pour votre migration :
- Utilisez l'adresse IP privée de votre hôte SQL Server source comme SOURCE_HOST_IP_ADDRESS.
- Utilisez l'adresse IP interne de votre point de terminaison Private Service Connect (règle de transfert) dans votre réseau cloud privé virtuel comme DESTINATION_HOST_IP_ADDRESS.

Configurer les règles de pare-feu du cloud privé virtuel et de l'hôte source

Dans votre réseau cloud privé virtuel, créez des règles de pare-feu d'entrée et de sortie qui autorisent le trafic TCP entre l'adresse IP de votre serveur SQL source (SOURCE_HOST_IP_ADDRESS) et la plage d'adresses IP de votre instance Cloud SQL pour SQL Server de destination (ou le point de terminaison Private Service Connect et le sous-réseau de rattachement de réseau) sur le port de base de données (1433 par défaut) et le port de mise en miroir de base de données (5022 par défaut). Pour en savoir plus sur la création de règles de pare-feu, consultez Créer des règles de pare-feu.
Sur votre machine SQL Server source, vérifiez les paramètres de pare-feu réseau et hôte suivants :
- TCP/IP est activé dans le gestionnaire de configuration SQL Server (ou mssql-conf sous Linux) et l'instance écoute sur un port TCP statique (1433 par défaut).
- Le pare-feu du système d'exploitation (tel que le pare-feu Windows Defender ou Linux iptables ou firewalld) autorise les connexions TCP entrantes sur le port de votre base de données (1433 par défaut) et sur le port de mise en miroir de votre base de données (5022 par défaut), ainsi que les connexions TCP sortantes vers DESTINATION_HOST_IP_ADDRESS sur le port 5022.

Vérifier la joignabilité avec les tests de connectivité Cloud SQL

Avant de configurer votre serveur associé, nous vous recommandons d'exécuter trois tests de connectivité à partir de l'onglet Connexions > Tests de connectivité de votre instance Cloud SQL pour SQL Server dans la console Google Cloud . Pour savoir comment exécuter un test de connectivité, consultez Gérer les tests de connectivité :

Pour tester la connectivité sortante du serveur associé sur le port 1433, définissez Source sur Instance Cloud SQL actuelle, Destination sur SOURCE_HOST_IP_ADDRESS et Port de destination sur 1433 (ou votre port de base de données personnalisé).
Pour tester la connectivité de mise en miroir de base de données sortante sur le port 5022, définissez Source sur Instance Cloud SQL actuelle, Destination sur SOURCE_HOST_IP_ADDRESS et Port de destination sur 5022 (ou votre port DBM personnalisé).
Pour tester la connectivité entrante de la mise en miroir de base de données sur le port 5022, définissez Source sur SOURCE_HOST_IP_ADDRESS, Destination sur Instance Cloud SQL actuelle (ou DESTINATION_HOST_IP_ADDRESS si vous utilisez Private Service Connect) et Port de destination sur 5022 (ou votre port DBM personnalisé).

Créer et vérifier le serveur associé sur votre instance Cloud SQL pour SQL Server de destination

Une fois votre connectivité réseau en place, connectez-vous à votre instance Cloud SQL pour SQL Server de destination et créez le serveur associé pointant vers votre instance SQL Server source :

Connectez-vous à votre instance Cloud SQL avec un client SQL. Vous pouvez utiliser les méthodes suivantes :
- Client sqlcmd. Vous pouvez utiliser cette méthode pour vous connecter à l'adresse IP privée de votre instance, mais vous devrez peut-être créer une machine virtuelle Compute Engine.
- Commande gcloud sql connect. Cette commande ne fonctionne que pour les instances Cloud SQL pour lesquelles une adresse IP publique est activée.

Connectez-vous en tant qu'utilisateur sqlserver et exécutez les commandes T-SQL suivantes pour votre version de Cloud SQL pour SQL Server de destination afin de créer un serveur associé pointant vers votre instance SQL Server source, de mapper @locallogin = N'sqlserver' à votre identifiant de migration source, d'activer rpc out et de tester la connexion avec OPENQUERY (pour en savoir plus sur les options de serveur associé sur Cloud SQL, consultez Gérer les serveurs associés) :

Cloud SQL pour SQL Server 2017, 2019 et 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 pour 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

Remplacez les éléments suivants :

LINKED_SERVER_NAME par le nom de votre serveur associé sur Cloud SQL pour SQL Server (par exemple, source_sql_linked_server).
SOURCE_HOST_IP_ADDRESS par l'adresse IP privée de votre instance SQL Server source (ou l'adresse IP de l'écouteur du groupe de disponibilité si elle est configurée pour un groupe de disponibilité source à plusieurs instances répliquées).
SOURCE_PORT_NUMBER par le numéro de port sur lequel votre moteur de base de données SQL Server source accepte les connexions (1433 par défaut).
SOURCE_USERNAME par le nom de l'identifiant SQL dédié que vous avez créé sur votre instance source dans Créer l'identifiant et les autorisations Database Migration Service dédiés.
SOURCE_PASSWORD par le mot de passe de l'identifiant SOURCE_USERNAME.

Créer des profils de connexion et exécuter le job de migration

Utilisez la Google Cloud CLI pour créer les profils de connexion source et de destination, créer le job de migration DAG continu, vérifier la configuration de la migration et démarrer le job de migration :

Créez le profil de connexion source.
Exécutez la commande gcloud database-migration connection-profiles create sqlserver (cliquez pour développer) :
gcloud database-migration connection-profiles create sqlserver

Cet exemple utilise l'option facultative --no-async pour que toutes les opérations soient effectuées de manière synchrone. Cela signifie que l'exécution de certaines commandes peut prendre un certain temps. Vous pouvez ignorer l'option --no-async pour exécuter des commandes de manière asynchrone. Si vous le faites, vous devez utiliser la commande gcloud database-migration operations describe pour vérifier si l'opération a réussi.
```
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
```
Remplacez les éléments suivants :
- SOURCE_CONNECTION_PROFILE_ID par un identifiant lisible par machine pour votre profil de connexion source (par exemple, sqlserver-dag-source-profile).
- SOURCE_CONNECTION_PROFILE_NAME par un nom lisible par l'humain pour votre profil de connexion source. Cette valeur s'affiche dans Database Migration Service dans la console Google Cloud .
- REGION par l'identifiant de la région dans laquelle vous souhaitez enregistrer le profil de connexion (par exemple, us-central1).
- SOURCE_HOST_IP_ADDRESS par l'adresse IP privée de votre instance SQL Server source (ou l'adresse IP de l'écouteur du groupe de disponibilité si elle est configurée pour un groupe de disponibilité source à plusieurs instances répliquées).
- SOURCE_PORT_NUMBER par le numéro de port sur lequel votre moteur de base de données SQL Server source accepte les connexions (1433 par défaut).
- SOURCE_DBM_PORT_NUMBER par le numéro de port TCP de votre point de terminaison de mise en miroir de base de données source (par défaut, 5022).
- SOURCE_USERNAME par le nom de l'identifiant SQL dédié que vous avez créé sur votre instance source dans Créer l'identifiant et les autorisations Database Migration Service dédiés.
- SOURCE_PASSWORD par le mot de passe de l'identifiant SOURCE_USERNAME.
Créez le profil de connexion de destination.
Exécutez la commande gcloud database-migration connection-profiles create sqlserver (cliquez pour développer) :
gcloud database-migration connection-profiles create sqlserver

Cet exemple utilise l'option facultative --no-async pour que toutes les opérations soient effectuées de manière synchrone. Cela signifie que l'exécution de certaines commandes peut prendre un certain temps. Vous pouvez ignorer l'option --no-async pour exécuter des commandes de manière asynchrone. Si vous le faites, vous devez utiliser la commande gcloud database-migration operations describe pour vérifier si l'opération a réussi.
```
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
```
Remplacez les éléments suivants :
- DESTINATION_CONNECTION_PROFILE_ID par un identifiant lisible par machine pour votre profil de connexion de destination (par exemple, sqlserver-dag-dest-profile).
- DESTINATION_CONNECTION_PROFILE_NAME par un nom lisible par l'humain pour votre profil de connexion de destination. Cette valeur s'affiche dans Database Migration Service dans la console Google Cloud .
- REGION par l'identifiant de la région dans laquelle vous souhaitez enregistrer le profil de connexion.
- CLOUDSQL_INSTANCE_ID par le nom de votre instance Cloud SQL pour SQL Server de destination.
- DESTINATION_HOST_IP_ADDRESS par l'adresse IP privée de votre instance Cloud SQL pour SQL Server de destination (ou l'adresse IP de son point de terminaison Private Service Connect) accessible depuis votre instance SQL Server source.
- DESTINATION_PORT_NUMBER par le numéro de port de la base de données de votre instance Cloud SQL pour SQL Server de destination (1433).
- DESTINATION_DBM_PORT_NUMBER par le numéro de port de mise en miroir de la base de données de votre instance Cloud SQL pour SQL Server de destination (5022).
- CLOUD_SQL_DB_USER_PASSWORD par le mot de passe de l'utilisateur sqlserver sur votre instance Cloud SQL pour SQL Server de destination (--username doit être défini sur sqlserver).
Créez le job de migration de DAG continu.
Exécutez la commande gcloud database-migration migration-jobs create (cliquez pour développer) :
gcloud database-migration migration-jobs create

Cet exemple utilise l'option facultative --no-async pour que toutes les opérations soient effectuées de manière synchrone. Cela signifie que l'exécution de certaines commandes peut prendre un certain temps. Vous pouvez ignorer l'option --no-async pour exécuter des commandes de manière asynchrone. Si vous le faites, vous devez utiliser la commande gcloud database-migration operations describe pour vérifier si l'opération a réussi.
```
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
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par un identifiant lisible par machine pour votre job de migration (par exemple, sqlserver-dag-job).
- MIGRATION_JOB_NAME par un nom lisible par l'humain pour votre job de migration. Cette valeur s'affiche dans la console Google Cloud .
- REGION par l'identifiant de la région dans laquelle vous souhaitez créer le job de migration.
- SOURCE_CONNECTION_PROFILE_ID par l'identifiant de votre profil de connexion source.
- DESTINATION_CONNECTION_PROFILE_ID par l'identifiant de votre profil de connexion de destination.
- SOURCE_AVAILABILITY_GROUP_NAME par le nom du groupe de disponibilité sur votre instance SQL Server source.
- LINKED_SERVER_NAME par le nom du serveur associé que vous avez configuré sur votre instance Cloud SQL pour SQL Server de destination dans Créer et vérifier le serveur associé sur votre instance Cloud SQL pour SQL Server de destination.
Vérifiez la configuration du job de migration.
Avant de lancer un job de migration de DAG, vous devez exécuter verify pour valider la connectivité réseau bidirectionnelle, l'accès RPC au serveur lié, les autorisations gcp_dms_db (si vous utilisez le principe du moindre privilège), les propriétaires de la base de données source (en vérifiant qu'aucune base de données n'appartient à sa) et les chemins d'accès par défaut aux fichiers de données. Exécutez la commande gcloud database-migration migration-jobs verify (cliquez pour développer) :
gcloud database-migration migration-jobs verify
```
gcloud database-migration migration-jobs verify MIGRATION_JOB_ID \
    --region=REGION
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par l'identifiant de votre job de migration.
- REGION par l'identifiant de la région où le job de migration est enregistré.
Vous pouvez vérifier l'état de l'opération de validation en exécutant la commande gcloud database-migration operations describe.
Démarrez le job de migration.
Une fois la validation réussie, exécutez la commande gcloud database-migration migration-jobs start (cliquez pour développer) :
gcloud database-migration migration-jobs start
```
gcloud database-migration migration-jobs start MIGRATION_JOB_ID \
    --region=REGION
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par l'identifiant de votre job de migration.
- REGION par l'identifiant de la région où le job de migration est enregistré.
Attention : Lorsque vous démarrez le job de migration DAG, Database Migration Service définit automatiquement l'option cloud sql enable dag support sur on sur votre instance Cloud SQL pour SQL Server de destination. Ne modifiez pas et ne supprimez pas manuellement l'option cloud sql enable dag support.

Surveiller et vérifier votre migration

Pendant l'exécution du job de migration DAG, vous pouvez surveiller sa progression dans la console Google Cloud , interroger vos bases de données de destination en mode lecture seule pendant CDC et gérer la réplication active.

Surveiller la progression dans la console Google Cloud

Vous pouvez surveiller un job de migration de DAG en cours d'exécution dans la console Google Cloud sur la page Détails du job de migration, comme les autres jobs de migration Database Migration Service :

Dans la table Bases de données de la page d'informations du job de migration, affichez la phase en temps réel (Full dump pendant le chargement complet initial, CDC pendant la réplication continue et tous les messages d'erreur au niveau de la base de données) et le retard de restauration pour chaque base de données de votre groupe de disponibilité.
Dans l'onglet Surveillance, affichez le graphique Délai de restauration (datamigration.googleapis.com/migration_job/max_replica_sec_lag, qui indique le délai de réplication du groupe de disponibilité distribué en secondes par base de données).

Pour en savoir plus sur les métriques de surveillance et les états des jobs, consultez Métriques des jobs de migration et Codes d'état des jobs de migration.

Vérifier les bases de données migrées en mode lecture seule pendant la CDC

Contrairement aux migrations basées sur des sauvegardes (où les bases de données de destination restent à l'état RESTORING jusqu'à la promotion), les migrations de groupes de disponibilité distribués vous permettent d'interroger vos bases de données Cloud SQL pour SQL Server de destination en mode lecture seule dès qu'elles entrent dans la phase CDC.

Pour chaque base de données appartenant à un identifiant SQL sur l'instance source, Database Migration Service crée automatiquement un identifiant sur l'instance Cloud SQL pour SQL Server de destination, précédé de gcp_dms_, d'un identifiant à six caractères et du nom du propriétaire source (par exemple, gcp_dms_a1b2c3_myowner). Pour interroger la base de données avec cet identifiant avant la promotion, connectez-vous à votre instance Cloud SQL pour SQL Server de destination en tant que sqlserver, recherchez le nom de l'identifiant généré dans sys.server_principals, puis réinitialisez son mot de passe :

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

Remplacez les éléments suivants :

GENERATED_DMS_OWNER_LOGIN par le nom de connexion du propriétaire de la base de données généré renvoyé par la requête.
NEW_OWNER_PASSWORD par un nouveau mot de passe pour la connexion.

Pour en savoir plus sur la vérification des objets et des données migrés, consultez Vérifier une migration.

Gérer un job de migration de DAG actif (facultatif)

Pendant l'exécution de votre job de migration en phase CDC, vous pouvez effectuer les opérations de gestion suivantes :

Ajoutez ou supprimez des bases de données dans votre groupe de disponibilité source sur votre instance SQL Server source en exécutant ALTER AVAILABILITY GROUP ... ADD DATABASE ou ALTER AVAILABILITY GROUP ... REMOVE DATABASE. Database Migration Service détecte automatiquement la modification lors de son prochain cycle d'interrogation et met à jour l'instance Cloud SQL pour SQL Server de destination.
Arrêtez temporairement la réplication des données en exécutant gcloud database-migration migration-jobs stop. L'arrêt d'un job de migration DAG ne doit être utilisé que pendant une période définie et courte, car les mises à jour continuent de s'accumuler dans les journaux de transactions pendant l'arrêt de la réplication, ce qui peut entraîner le remplissage des disques de journaux de transactions. À partir d'un état arrêté, vous pouvez exécuter gcloud database-migration migration-jobs resume pour reprendre la réplication des données ou exécuter gcloud database-migration migration-jobs delete pour terminer la migration et effectuer le nettoyage nécessaire.
Redémarrez un job de migration ayant échoué en exécutant gcloud database-migration migration-jobs restart. Le redémarrage d'un job de migration DAG supprime les bases de données migrées sur votre instance Cloud SQL pour SQL Server de destination, recrée le groupe de disponibilité distribué et réexécute le chargement complet initial sur le réseau.

Promouvoir, effectuer un failback ou terminer la migration

Lorsque vous êtes prêt à basculer vos applications vers Cloud SQL pour SQL Server, promouvez le job de migration. Dans une migration de DAG, la promotion du job fait passer Cloud SQL pour SQL Server en mode principal en lecture/écriture et fait passer le job de migration à la phase FAILBACK (PHASE_FAILBACK dans la Google Cloud CLI et les réponses de l'API) avec une réplication inverse active vers votre instance SQL Server source :

Arrêtez les écritures d'application dans vos bases de données SQL Server sources et vérifiez la métrique Délai de restauration dans la console Google Cloud pour confirmer que le délai de réplication a atteint zéro.
Promouvez le job de migration pour basculer vers Cloud SQL.
Exécutez la commande gcloud database-migration migration-jobs promote (cliquez pour développer) :
gcloud database-migration migration-jobs promote
```
gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
    --region=REGION
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par l'identifiant de votre job de migration.
- REGION par l'identifiant de la région où le job de migration est enregistré.
Lors de la promotion, Database Migration Service effectue les actions suivantes :
- Définit le groupe de disponibilité distribué sur la validation synchrone, émet un CHECKPOINT sur toutes les bases de données sources, attend que toutes les transactions se synchronisent sans perte de données et inverse les rôles du groupe de disponibilité afin que votre instance Cloud SQL pour SQL Server de destination devienne l'instance principale en lecture/écriture et que votre instance SQL Server source d'origine devienne l'instance secondaire.
- Conserve le job de migration à l'état Running et fait passer le sous-état à la phase FAILBACK (PHASE_FAILBACK dans Google Cloud CLI et les réponses de l'API), en répliquant en continu les nouvelles écritures de votre instance Cloud SQL pour SQL Server de destination vers l'instance SQL Server source.
Une fois la promotion terminée, connectez vos applications à votre nouvelle instance Cloud SQL pour SQL Server.
(Facultatif) Effectuez un failback vers votre instance SQL Server source.
Si vous rencontrez un problème après avoir basculé vos applications vers Cloud SQL pour SQL Server alors que le job de migration est en phase FAILBACK, vous pouvez annuler le basculement sans aucune perte de données en arrêtant les écritures d'application sur Cloud SQL pour SQL Server et en exécutant la commande gcloud database-migration migration-jobs promote avec l'option --failback (cliquez pour développer) :
gcloud database-migration migration-jobs promote --failback
```
gcloud database-migration migration-jobs promote MIGRATION_JOB_ID \
    --region=REGION \
    --failback
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par l'identifiant de votre job de migration.
- REGION par l'identifiant de la région où le job de migration est enregistré.
L'exécution de promote avec l'option --failback pendant la phase FAILBACK synchronise toutes les modifications écrites dans Cloud SQL pour SQL Server, change à nouveau le sens de la réplication pour que votre groupe de disponibilité SQL Server source d'origine devienne l'instance principale en lecture/écriture et que Cloud SQL pour SQL Server devienne l'instance secondaire, puis renvoie le job de migration à la phase CDC. Notez que --failback n'est valide que lorsque le job de migration est en phase FAILBACK. L'exécution de promote sans --failback pendant la phase FAILBACK (ou la transmission de --failback pendant la phase CDC) échoue à la validation avec une erreur FAILED_PRECONDITION et laisse le job de migration en cours d'exécution.
(Facultatif) Arrêtez la réplication des données avant de supprimer le job de migration.
Si vous souhaitez arrêter la réplication des données avant de supprimer définitivement le job de migration, exécutez la commande gcloud database-migration migration-jobs stop (cliquez pour développer) :
gcloud database-migration migration-jobs stop
```
gcloud database-migration migration-jobs stop MIGRATION_JOB_ID \
    --region=REGION
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par l'identifiant de votre job de migration.
- REGION par l'identifiant de la région où le job de migration est enregistré.
Attention : L'arrêt d'un job de migration interrompt la réplication des données, mais ne doit être utilisé que pendant une période définie et courte, car les mises à jour continuent de s'accumuler dans les journaux de transactions pendant l'arrêt de la réplication. À partir d'un état Stopped, vous pouvez exécuter gcloud database-migration migration-jobs resume pour reprendre la réplication des données, ou exécuter gcloud database-migration migration-jobs delete à l'étape suivante pour terminer la migration et effectuer le nettoyage nécessaire.
Terminez la migration et supprimez le job de migration.
Une fois que vous avez vérifié que vos applications sont entièrement opérationnelles avec la nouvelle instance de destination Cloud SQL pour SQL Server et que vous n'avez plus besoin de la réplication inverse vers l'instance SQL Server source, supprimez le job de migration (à partir de l'état Running ou Stopped) pour terminer la migration et effectuer le nettoyage nécessaire. Exécutez la commande gcloud database-migration migration-jobs delete (cliquez pour développer) :
gcloud database-migration migration-jobs delete

Cette commande renvoie une invite de confirmation interactive qui nécessite votre intervention pour se terminer. Vous pouvez ignorer l'invite de confirmation à l'aide de l' option facultative --quiet.
```
gcloud database-migration migration-jobs delete MIGRATION_JOB_ID \
    --region=REGION
```
Remplacez les éléments suivants :
- MIGRATION_JOB_ID par l'identifiant de votre job de migration.
- REGION par l'identifiant de la région où le job de migration est enregistré.
La suppression du job de migration finalise la migration, arrête toute réplication inverse active, supprime les certificats de groupe de disponibilité distribué et de mise en miroir de base de données sur les deux instances, et vous permet d'activer les fonctionnalités Cloud SQL pour SQL Server qui sont limitées pendant la réplication DAG (comme la récupération à un moment précis (PITR) ou les instances dupliquées avec accès en lecture).

Après avoir supprimé le job de migration, vous pouvez éventuellement désactiver ou supprimer l'indicateur de base de données cloud sql enable dag support sur votre instance Cloud SQL pour SQL Server de destination, supprimer le serveur associé sur votre instance Cloud SQL pour SQL Server (EXEC master.dbo.sp_dropserver @server = N'LINKED_SERVER_NAME', @droplogins = 'droplogins';) et supprimer la base de données d'assistance gcp_dms_db et l'identifiant de migration sur votre instance SQL Server source.

Migrer depuis SQL Server autogéré à l'aide de groupes de disponibilité distribués

Coûts

Avant de commencer

Rôles requis

Créer et préparer votre instance Cloud SQL pour SQL Server de destination

Préparer votre instance SQL Server source

Activer les groupes de disponibilité Always On

Créer le point de terminaison et le certificat de mise en miroir de la base de données

Attribuer le rôle sysadmin

Moindre privilège (gcp_dms_db)

Préparer vos bases de données sources et votre groupe de disponibilité

Établir une connectivité réseau privée bidirectionnelle

Ports et adresses IP requis

Configurer votre méthode de mise en réseau privée

Accès aux services privés

Private Service Connect

Configurer les règles de pare-feu du cloud privé virtuel et de l'hôte source

Vérifier la joignabilité avec les tests de connectivité Cloud SQL

Créer et vérifier le serveur associé sur votre instance Cloud SQL pour SQL Server de destination

Cloud SQL pour SQL Server 2017, 2019 et 2022

Cloud SQL pour SQL Server 2025

Créer des profils de connexion et exécuter le job de migration

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration migration-jobs create`

`gcloud database-migration migration-jobs verify`

`gcloud database-migration migration-jobs start`

Surveiller et vérifier votre migration

Surveiller la progression dans la console Google Cloud

Vérifier les bases de données migrées en mode lecture seule pendant la CDC

Gérer un job de migration de DAG actif (facultatif)

Promouvoir, effectuer un failback ou terminer la migration

`gcloud database-migration migration-jobs promote`

`gcloud database-migration migration-jobs promote --failback`

`gcloud database-migration migration-jobs stop`

`gcloud database-migration migration-jobs delete`

Migrer depuis SQL Server autogéré à l'aide de groupes de disponibilité distribués Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Coûts

Avant de commencer

Rôles requis

Créer et préparer votre instance Cloud SQL pour SQL Server de destination

Préparer votre instance SQL Server source

Activer les groupes de disponibilité Always On

Créer le point de terminaison et le certificat de mise en miroir de la base de données

Créer l'identifiant et les autorisations dédiés à Database Migration Service

Attribuer le rôle sysadmin

Moindre privilège (gcp_dms_db)

Préparer vos bases de données sources et votre groupe de disponibilité

Établir une connectivité réseau privée bidirectionnelle

Ports et adresses IP requis

Configurer votre méthode de mise en réseau privée

Accès aux services privés

Private Service Connect

Configurer les règles de pare-feu du cloud privé virtuel et de l'hôte source

Vérifier la joignabilité avec les tests de connectivité Cloud SQL

Créer et vérifier le serveur associé sur votre instance Cloud SQL pour SQL Server de destination

Cloud SQL pour SQL Server 2017, 2019 et 2022

Cloud SQL pour SQL Server 2025

Créer des profils de connexion et exécuter le job de migration

gcloud database-migration connection-profiles create sqlserver

gcloud database-migration connection-profiles create sqlserver

gcloud database-migration migration-jobs create

gcloud database-migration migration-jobs verify

gcloud database-migration migration-jobs start

Surveiller et vérifier votre migration

Surveiller la progression dans la console Google Cloud

Vérifier les bases de données migrées en mode lecture seule pendant la CDC

Gérer un job de migration de DAG actif (facultatif)

Promouvoir, effectuer un failback ou terminer la migration

gcloud database-migration migration-jobs promote

gcloud database-migration migration-jobs promote --failback

gcloud database-migration migration-jobs stop

gcloud database-migration migration-jobs delete

Migrer depuis SQL Server autogéré à l'aide de groupes de disponibilité distribués

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration connection-profiles create sqlserver`

`gcloud database-migration migration-jobs create`

`gcloud database-migration migration-jobs verify`

`gcloud database-migration migration-jobs start`

`gcloud database-migration migration-jobs promote`

`gcloud database-migration migration-jobs promote --failback`

`gcloud database-migration migration-jobs stop`

`gcloud database-migration migration-jobs delete`