À propos des migrations de groupes de disponibilité distribués (DAG)

En plus du flux de migration standard de sauvegarde et de restauration Cloud Storage, Database Migration Service permet de migrer des bases de données SQL Server autogérées vers Cloud SQL pour SQL Server à l'aide de groupes de disponibilité distribués (DAG) SQL Server.

Au lieu d'exporter et d'importer des fichiers de sauvegarde et de journaux de transactions dans un bucket Cloud Storage, Database Migration Service configure un groupe de disponibilité distribué entre votre groupe de disponibilité source et un groupe de disponibilité secondaire géré sur votre instance Cloud SQL pour SQL Server de destination. Cette configuration diffuse à la fois le chargement complet initial et les modifications de base de données en cours directement via une connexion réseau privée.

Cette page aborde les sujets suivants :

Quand utiliser les migrations de DAG ?

Le tableau suivant compare les migrations de sauvegarde et de restauration standards avec les migrations de groupe de disponibilité distribué (DAG) pour vous aider à choisir la meilleure approche pour votre charge de travail :

Fonctionnalité ou exigence Migrations standards de sauvegarde et de restauration (guide de migration standard) Migrations de groupes de disponibilité distribués (DAG) (guide de migration des DAG)
Sources compatibles SQL Server autogéré, Amazon RDS et Cloud SQL pour SQL Server. SQL Server autogéré (Enterprise Edition) avec des groupes de disponibilité AlwaysOn.
Mécanisme de transfert de données Fichiers de sauvegarde complète (.bak), de sauvegarde différentielle facultative (.diff) et de journal des transactions (.trn) stockés dans Cloud Storage. Streaming réseau direct via un point de terminaison de mise en miroir de base de données SQL Server (DBM) (aucun fichier de sauvegarde ni bucket Cloud Storage n'est requis).
Connectivité réseau Aucune connectivité n'est requise entre la source et la destination. Une connectivité IP privée bidirectionnelle est requise sur le port de la base de données SQL Server (1433 par défaut) et sur le port de mise en miroir de la base de données (5022 par défaut).
Accès à la base de données de destination pendant la migration Les bases de données restent en mode RESTORING (inaccessibles aux requêtes) jusqu'à la promotion. Les bases de données sont accessibles en mode lecture seule pendant la phase de réplication continue (CDC).
Failback post-promotion Non compatible (promotion unidirectionnelle). Réplication inverse intégrée (phase FAILBACK) de Cloud SQL pour SQL Server vers l'instance SQL Server source après la promotion, avec prise en charge du basculement sans perte de données.

Fonctionnement des migrations de DAG

Lors d'une migration DAG, Database Migration Service orchestre la réplication des données entre votre groupe de disponibilité source et un groupe de disponibilité secondaire géré sur votre instance Cloud SQL pour SQL Server de destination.

Canaux de communication réseau

Database Migration Service utilise deux canaux de communication réseau privés entre votre instance SQL Server source et votre instance Cloud SQL pour SQL Server de destination :

  1. Serveur associé SQL Server (port de base de données, par défaut 1433) : Database Migration Service utilise un serveur associé configuré sur l'instance Cloud SQL pour SQL Server de destination pour exécuter des requêtes d'administration et d'orchestration sur l'instance SQL Server source.
  2. Point de terminaison de mise en miroir de base de données (DBM) (par défaut 5022) : le groupe de disponibilité source et le groupe de disponibilité Cloud SQL pour SQL Server de destination échangent des données de chargement complet initial authentifiées par certificat et des modifications de base de données en cours directement via le port DBM.

Phases du cycle de vie de la migration

Un job de migration de DAG passe par quatre phases de cycle de vie :

  1. Chargement complet initial (FULL_DUMP) : lorsque vous démarrez le job de migration, Database Migration Service configure le groupe de disponibilité distribué pour diffuser la copie complète initiale de toutes les bases de données du groupe de disponibilité source sur le réseau vers l'instance Cloud SQL pour SQL Server de destination.
  2. Réplication continue (CDC) : une fois que chaque base de données a terminé son chargement complet initial, elle passe à la phase CDC. Les modifications apportées aux bases de données sources sont répliquées en continu sur le point de terminaison DBM. Vous pouvez vous connecter à l'instance Cloud SQL pour SQL Server de destination pour exécuter des requêtes de validation en lecture seule sur les bases de données en cours de réplication.
  3. Promotion et réplication inverse (FAILBACK) : lorsque vous promouvez le job de migration (promote sans l'option --failback), Database Migration Service synchronise les deux groupes de disponibilité, inverse leurs rôles de sorte que l'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, puis fait passer la phase du job de migration à FAILBACK (PHASE_FAILBACK dans Google Cloud CLI et les réponses de l'API). Pendant la phase FAILBACK, le job de migration reste à l'état Running et réplique les nouvelles écritures de Cloud SQL pour SQL Server vers votre instance SQL Server source.
  4. Commutation, arrêt ou achèvement du basculement (Stop et Delete) :
    • Si vous devez annuler votre basculement pendant la phase FAILBACK, vous pouvez exécuter la commande promote avec l'option --failback (failback = true dans l'API) pour effectuer un basculement de retour sans perte de données qui restaure votre instance SQL Server source d'origine en tant qu'instance principale, rétrograde Cloud SQL pour SQL Server en tant qu'instance secondaire et renvoie le job de migration à la phase CDC.
    • Vous pouvez exécuter stop pour interrompre la réplication des données pendant une courte période définie (les mises à jour continuent de s'accumuler dans les journaux de transactions pendant l'interruption de la réplication). À partir d'un état Stopped, vous pouvez exécuter resume pour reprendre la réplication des données ou exécuter delete pour terminer la migration et effectuer le nettoyage nécessaire.
    • Une fois que vous avez confirmé que le basculement vers Cloud SQL pour SQL Server est permanent, vous supprimez (delete) le job de migration (directement ou à partir de l'état Stopped). La suppression du job de migration termine la migration, supprime le groupe de disponibilité distribué et les certificats sur les deux instances, et vous permet d'activer les fonctionnalités Cloud SQL pour SQL Server qui sont bloquées pendant la migration, telles que la récupération à un moment précis (PITR) et les instances dupliquées avec accès en lecture.

Bases de données source et de destination acceptées

Les migrations DAG sont compatibles avec les éditions et versions de bases de données sources et de destination suivantes :

  • Bases de données sources : SQL Server Enterprise Edition autogéré (versions 2017, 2019, 2022 et 2025) avec la fonctionnalité Groupes de disponibilité Always On activée (sur Windows ou Linux).
  • Bases de données de destination : Cloud SQL pour SQL Server Enterprise Edition (versions 2017, 2019, 2022 et 2025).

Limites connues pour les migrations de DAG

Tenez compte des limites suivantes avant de configurer une migration de DAG :

  • La création de profils de connexion DAG et la création, la vérification, le démarrage, la promotion ou la suppression de jobs de migration DAG ne sont possibles qu'à l'aide de la Google Cloud CLI ou de l'API Database Migration Service. Vous pouvez surveiller la progression du job de migration DAG, l'état par base de données et les métriques dans la console Google Cloud .
  • L'instance SQL Server source et l'instance Cloud SQL pour SQL Server de destination doivent toutes deux exécuter l'édition Enterprise. Les sources Amazon RDS et Cloud SQL pour SQL Server ne sont pas compatibles avec les migrations DAG.
  • Chaque job de migration DAG migre toutes les bases de données contenues dans un seul groupe de disponibilité source (dans la limite de 100 bases de données par groupe de disponibilité distribué). Les bases de données système (master, model, msdb, tempdb) et la base de données d'assistance Database Migration Service (gcp_dms_db) ne sont pas migrées.
  • Toutes les bases de données du groupe de disponibilité source doivent stocker leurs fichiers de données (.mdf et .ndf) dans le répertoire de données SQL Server par défaut.
  • Exigences concernant la propriété de la base de données :
    • Les bases de données sources ne peuvent pas appartenir à l'identifiant sa. Avant de lancer le job de migration, remplacez le propriétaire de la base de données sa par un autre identifiant SQL ou utilisateur Windows.
    • Si une base de données source appartient à un utilisateur Windows Active Directory, vous devez soit remplacer le propriétaire de la base de données source par un identifiant SQL avant la migration, soit intégrer votre 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 les propriétaires de bases de données authentifiés par SQL, Database Migration Service crée automatiquement un identifiant correspondant 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 être propriétaire de la base de données migrée.
  • La connectivité IP publique n'est pas compatible. Vous devez configurer la connectivité IP privée entre l'instance SQL Server source et l'instance Cloud SQL pour SQL Server de destination à l'aide de l'accès aux services privés ou de Private Service Connect.
  • Restrictions concernant l'instance Cloud SQL pour SQL Server de destination pendant l'existence du job de migration DAG : entre le moment où vous démarrez un job de migration DAG et celui où vous le supprimez (y compris pendant la phase FAILBACK post-promotion) :
    • La récupération à un moment précis (PITR) doit être désactivée sur l'instance Cloud SQL pour SQL Server de destination.
    • Les instances dupliquées avec accès en lecture et les pools de lecture ne sont pas compatibles avec l'instance Cloud SQL pour SQL Server de destination.
    • La maintenance planifiée avec un temps d'arrêt quasiment nul n'est pas compatible avec l'instance Cloud SQL pour SQL Server de destination.
    • Ne modifiez pas manuellement l'indicateur de base de données cloud sql enable dag support sur l'instance Cloud SQL pour SQL Server de destination. Database Migration Service active automatiquement cet indicateur au démarrage du job de migration, et vous pouvez le supprimer après avoir supprimé le job de migration.
  • Ajout ou suppression de bases de données pendant la migration :
    • Vous pouvez ajouter ou supprimer dynamiquement des bases de données dans votre groupe de disponibilité source pendant que le job de migration est en phase CDC. Database Migration Service détecte automatiquement les bases de données nouvellement ajoutées, les valide et effectue leur chargement complet initial vers l'instance Cloud SQL pour SQL Server de destination.
    • La suppression d'une base de données du groupe de disponibilité source arrête la réplication de cette base de données, la supprime des objets suivis du job de migration et la laisse à l'état RESTORING sur l'instance Cloud SQL pour SQL Server de destination (elle n'est pas récupérée lorsque le job est promu).
    • L'ajout de nouvelles bases de données directement sur l'instance Cloud SQL pour SQL Server de destination pendant la phase FAILBACK post-promotion n'est pas possible (le groupe de disponibilité de destination n'est pas mis à jour avec les nouvelles bases de données créées sur Cloud SQL).
  • Remarques concernant l'arrêt, la reprise et le redémarrage des jobs de migration de DAG :
    • L'arrêt (stop) d'un job de migration DAG interrompt la réplication des données, ce qui entraîne l'accumulation des mises à jour dans les journaux de transactions pendant l'arrêt de la réplication. N'arrêtez un job de migration DAG que pour une période définie et courte, afin que les disques de journaux de transactions ne se remplissent pas. À partir de l'état Stopped, vous pouvez exécuter resume pour reprendre la réplication des données ou exécuter delete pour terminer la migration et effectuer le nettoyage nécessaire.
    • Le redémarrage (restart) d'un job de migration DAG ayant échoué ou arrêté supprime les bases de données migrées sur l'instance Cloud SQL pour SQL Server de destination et réexécute le chargement complet initial (FULL_DUMP) sur le réseau.

Étapes suivantes