Migrer une base de données SQL Server d'AWS EC2 vers Compute Engine

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Préparer le projet et le réseau

Pour préparer votre Google Cloud projet et votre cloud privé virtuel (VPC) au déploiement de SQL Server pour la migration, procédez comme suit:

1. Dans la Google Cloud console, cliquez sur Activer Cloud Shell pour ouvrir Cloud Shell.

   Accéder à la Google Cloud console

2. Définissez votre ID de projet par défaut :

   gcloud config set project PROJECT_ID
   

   Remplacez PROJECT_ID par l'ID de votre Google Cloud projet.

3. Définissez votre région par défaut :

   gcloud config set compute/region REGION
   

   Remplacez REGION par l'ID de la région dans laquelle vous souhaitez effectuer le déploiement.

4. Définissez votre zone par défaut :

   gcloud config set compute/zone ZONE
   

   Remplacez ZONE par l'ID de la zone dans laquelle vous souhaitez effectuer le déploiement. Assurez-vous que la zone est valide dans la région que vous avez spécifiée à l'étape précédente.

Créer une instance SQL Server sur Compute Engine

Avant de migrer votre base de données SQL Server vers Compute Engine, vous devez créer une machine virtuelle (VM) sur Compute Engine pour l'héberger.

Utilisez la commande suivante pour créer une instance SQL Server sur Compute Engine:

gcloud compute instances create sql-server-std-migrate-vm \
--project=PROJECT_ID \
--zone ZONE \
--machine-type n4-standard-8 \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-standard-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

gcloud compute instances create sql-server-ent-migrate-vm \
--project=PROJECT_ID \
--zone ZONE \
--machine-type n4-standard-8 \
--subnet SUBNET_NAME \
--create-disk=auto-delete=yes,boot=yes,device-name=node-1,image=projects/windows-sql-cloud/global/images/sql-2022-enterprise-windows-2022-dc-v20250213,mode=rw,size=50,type=projects/PROJECT_ID/zones/ZONE/diskTypes/pd-balanced \
--scopes=https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/servicecontrol,https://www.googleapis.com/auth/service.management.readonly,https://www.googleapis.com/auth/logging.write,https://www.googleapis.com/auth/monitoring.write,https://www.googleapis.com/auth/trace.append,https://www.googleapis.com/auth/devstorage.read_write

Pour en savoir plus sur la création d'instances SQL Server sur Compute Engine, consultez Créer une instance SQL Server.

Configurer et se connecter à votre VM SQL Server

Pour configurer votre VM SQL Server et vous y connecter, procédez comme suit:

1. Définissez le mot de passe Windows initial pour votre compte:

   1. Dans la console Google Cloud , accédez à la page Instances de VM.

      Accéder à la page "Instances de VM"

   2. Cliquez sur le nom de la VM SQL Server.

   3. Cliquez sur le bouton Définir un mot de passe Windows.

   4. Saisissez un mot de passe, puis cliquez sur Définir lorsque vous y êtes invité pour définir le nouveau mot de passe Windows.

   5. Enregistrez le nom d'utilisateur et le mot de passe.

2. Connectez-vous à la VM SQL Server:

   1. Utilisez l'adresse IP publique de la VM SQL Server sur la page Instances de VM et les identifiants enregistrés à l'étape précédente pour vous connecter à votre VM SQL Server à l'aide de Microsoft Remote Desktop (RDP).

   2. Exécutez SQL Server Management Studio (SSMS) en tant qu'administrateur.

   3. Vérifiez que la case à cocher Approuver le certificat du serveur est sélectionnée, puis cliquez sur Se connecter.

Votre VM SQL Server est maintenant prête à être utilisée pour la migration de bases de données. Pour créer des identifiants utilisateur permettant de se connecter et de gérer votre VM SQL Server, consultez Créer un identifiant.

Sauvegarde et restauration complètes de la base de données

La sauvegarde et la restauration complètes de la base de données sont la méthode de migration de base de données la plus courante et la plus simple. Avec cette approche, une sauvegarde complète de la base de données SQL Server est effectuée à partir de l'environnement source, puis restaurée dans l'environnement de destination. Google Cloud Bien que cette méthode soit relativement simple, elle peut être chronophage pour les bases de données volumineuses en raison du temps nécessaire pour créer et restaurer la sauvegarde.

Cette section explique comment utiliser SSMS pour exporter votre base de données SQL Server à l'aide d'un exemple de base de données AdventureWorks2022.

Créer une sauvegarde complète de la base de données

Pour créer une sauvegarde complète de la base de données, procédez comme suit:

1. Connectez-vous à votre VM AWS EC2 à l'aide de Microsoft RDP.

2. Connectez-vous à SQL Server à l'aide de SSMS.

3. Développez le dossier "databases" dans l'explorateur d'objets.

4. Effectuez un clic droit sur le nom de la base de données, puis cliquez sur Tâches dans le menu.

5. Cliquez sur Sauvegarder pour ouvrir l'assistant de sauvegarde de la base de données.

   1. Vérifiez que le nom de la base de données à sauvegarder est correct et que le type de sauvegarde est défini sur "Full" (Complète).

   2. Cliquez sur Ajouter sous la destination de la sauvegarde complète.

   3. Cliquez sur l'icône des points de suspension (…) pour sélectionner le dossier et le nom du fichier de sauvegarde.

   4. Cliquez sur OK pour définir le nom du fichier, puis de nouveau sur OK pour définir la destination.

      

   5. Cliquez sur OK pour démarrer la sauvegarde de la base de données et attendez qu'elle soit terminée.

      Une fois le processus de sauvegarde terminé, un fichier de sauvegarde est créé. Vous pouvez maintenant utiliser ce fichier de sauvegarde pour migrer le contenu de la base de données vers une VM Compute Engine.

   6. Cliquez sur OK pour quitter l'assistant de sauvegarde de la base de données.

Transférer le fichier de sauvegarde vers une VM Compute Engine

Pour migrer le contenu de votre base de données SQL Server, vous devez transférer le fichier de sauvegarde créé à l'étape précédente vers la VM Compute Engine que vous avez créée. Pour en savoir plus sur les différentes options de transfert, consultez la section Transférer des fichiers vers des VM Windows.

Restaurer votre base de données SQL Server à partir du fichier de sauvegarde

Pour restaurer la base de données à partir du fichier de sauvegarde, procédez comme suit:

1. Connectez-vous à votre VM Compute Engine à l'aide de RDP.

2. Connectez-vous à SQL Server à l'aide de SSMS.

3. Dans l'explorateur d'objets, faites un clic droit sur le dossier Databases (Bases de données), puis cliquez sur Restore Database (Restaurer la base de données).

4. Dans Source, cliquez sur Device (Appareil) et sur l'icône en forme de points de suspension (...) pour ouvrir la page "Sélectionner un appareil de sauvegarde".

5. Vérifiez que le type de support de sauvegarde est défini sur "File" (Fichier), puis cliquez sur Add (Ajouter) pour sélectionner le fichier de sauvegarde.

   

6. Cliquez sur OK pour définir le fichier de sauvegarde comme appareil de restauration.

7. Cliquez sur OK pour restaurer la base de données.

   Une fois le processus terminé, votre base de données est migrée vers le SQL Server de destination sur Compute Engine.

8. Pour vérifier si le processus a bien été effectué, vous pouvez développer le dossier databases (Bases de données) dans l'explorateur d'objets et vérifier si la base de données migrée s'affiche.

   

Migrer à l'aide d'un fichier BACPAC

Un fichier de package de sauvegarde (BACPAC) est une représentation logique d'une base de données SQL Server. Il peut être exporté depuis l'environnement AWS source, puis importé dans l'environnement Google Cloud de destination. Cette méthode est généralement plus rapide qu'une sauvegarde et une restauration complètes pour les petites bases de données, mais elle peut ne pas convenir aux bases de données très volumineuses ou celles présentant des dépendances complexes.

La section suivante explique comment migrer votre base de données SQL Server à l'aide d'un fichier BACPAC.

Créer une exportation BACPAC

Pour créer une export BACPAC, procédez comme suit:

1. Connectez-vous à la VM AWS EC2 à l'aide du protocole RDP Microsoft.

2. Connectez-vous à SQL Server à l'aide de SSMS.

3. Développez le dossier databases dans l'explorateur d'objets.

4. Effectuez un clic droit sur le nom de la base de données, puis cliquez sur Tasks (Tâches).

5. Cliquez sur Exporter l'application de niveau de données pour ouvrir l'assistant d'exportation.

   1. Cliquez sur Suivant.

   2. Cliquez sur Parcourir dans l'option Enregistrer sur le disque local, puis sélectionnez le fichier BACPAC.

   3. Cliquez sur l'onglet Avancé, puis sélectionnez le ou les schémas à exporter.

   4. Cliquez sur Suivant pour accéder au récapitulatif.

   5. Cliquez sur Finish (Terminer) pour exporter le fichier BACPAC et attendez que l'exportation soit terminée.

   6. Cliquez sur Close (Fermer) pour quitter l'assistant.

6. Transférez le fichier BACPAC créé aux étapes précédentes vers votre VM de destination sur Compute Engine. Pour en savoir plus sur les options de transfert, consultez la section Transférer des fichiers vers des VM Windows.

Restaurer votre base de données SQL Server à partir d'un fichier BACPAC

Pour restaurer la base de données à partir du fichier BACPAC, procédez comme suit:

1. Connectez-vous à la VM Compute Engine à l'aide de RDP.

2. Connectez-vous à SQL Server à l'aide de SSMS.

3. Dans l'explorateur d'objets, effectuez un clic droit sur le dossier Databases (Bases de données), puis cliquez sur Import Data-tier Application (Importer une application de niveau de données).

4. Cliquez sur Suivant.

5. Cliquez sur Parcourir, sélectionnez le fichier BACPAC que vous souhaitez restaurer, puis cliquez sur Suivant.

6. Vérifiez le nom de la nouvelle base de données, puis cliquez sur Suivant.

7. Cliquez sur Finish (Terminer) et attendez que l'importation soit terminée.

8. Cliquez sur Close (Fermer) pour quitter l'assistant.

9. Pour vérifier si le processus a bien été effectué, vous pouvez développer le dossier databases (Bases de données) dans l'explorateur d'objets et vérifier si la base de données migrée s'affiche.

Migrer à l'aide de groupes de disponibilité Always-on

Un AOAG est une fonctionnalité de haute disponibilité et de reprise après sinistre de SQL Server. Vous pouvez utiliser un AOAG pour migrer des clusters AOAG existants, des serveurs SQL autonomes et des clusters de basculement Windows Server (WSFC). Avec cette méthode, un réplica de la base de données est créé dans l'environnement Google Cloud de destination, et les données sont synchronisées entre la source et la cible. Une fois la synchronisation terminée, vous pouvez définir le réplica sur l'environnement Google Cloud de destination comme principal. Cette méthode minimise les temps d'arrêt, mais nécessite une configuration et une configuration supplémentaires. Pour les migrations simples avec une tolérance de temps d'arrêt importante, d'autres méthodes peuvent être plus simples et plus rentables.

Avant de commencer

Avant de commencer la migration, vérifiez les points suivants:

• Pour assurer une transition sécurisée et fluide des données, établissez une connexion de peering entre AWS et Google Cloud. Pour en savoir plus, consultez Créer des connexions VPN haute disponibilité entre Google Cloud et AWS.

• Assurez-vous que la base de données source s'exécute en mode autonome et que les serveurs source et de destination sont joints à un Active Directory (AD). Si la base de données source fait déjà partie d'un cluster WSFC utilisant un AOAG, consultez la section Migrer à l'aide de groupes de disponibilité distribués.

• Assurez-vous que toutes les clés de chiffrement de la base de données SQL Server source sont installées sur toutes les instances SQL Server qui rejoindront l'AOAG.

Préparer votre SQL Server à faire partie d'un AOAG

Pour pouvoir ajouter des serveurs SQL à un AOAG, vous devez activer la fonctionnalité AOAG sur toutes les instances SQL Server que vous souhaitez ajouter au groupe.

Pour activer la fonctionnalité AOAG sur toutes les VM SQL Server que vous souhaitez ajouter à un AOAG, procédez comme suit:

1. Activez AOAG sur votre SQL Server.

   1. Connectez-vous à votre VM SQL Server à l'aide de RDP.

   2. Ouvrez Powershell en mode administrateur.

   3. Exécutez la commande suivante pour activer AOAG sur votre serveur SQL.

      Enable-SqlAlwaysOn -ServerInstance $env:COMPUTERNAME -Force
      

   4. Exécutez la commande suivante pour ouvrir un port de pare-feu pour la réplication de données.

      netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
      

   5. Répétez l'étape 1 pour toutes les VM SQL Server que vous souhaitez ajouter à l'AOAG.

2. Créez un utilisateur pour votre SQL Server dans votre AD.

   $Credential = Get-Credential -UserName sql_server -Message 'Enter password'
   New-ADUser `
   -Name "sql_server" `
   -Description "SQL Admin account." `
   -AccountPassword $Credential.Password `
   -Enabled $true -PasswordNeverExpires $true
   

3. Pour toutes les instances SQL Server faisant partie de l'AOAG, procédez comme suit:

   1. Accédez à l'outil Gestionnaire de configuration SQL Server.
   2. Dans le volet de navigation, sélectionnez Services SQL Server.
   3. Dans la liste des services, faites un clic droit sur SQL Server (MSSQLSERVER), puis sélectionnez Propriétés.
   4. Sous Se connecter en tant que, modifiez le compte comme suit :
      • Nom du compte:DOMAIN\sql_server, où DOMAIN est le nom NetBIOS de votre domaine AD.
      • Mot de passe:saisissez le mot de passe que vous avez choisi à l'étape 2 de cette section.

   5. Cliquez sur OK.

   6. Lorsque vous êtes invité à redémarrer SQL Server, sélectionnez Oui.

SQL Server s'exécute désormais sous un compte utilisateur de domaine.

Configurer le point de terminaison de la réplication pour votre base de données SQL Server

Pour créer le point de terminaison de votre AOAG, procédez comme suit:

1. Si la base de données SQL Server source est chiffrée avec le chiffrement transparent des données (TDE, Transparent Data Encryption), effectuez cette étape pour sauvegarder, transférer et installer les certificats et les clés sur le serveur SQL de destination.

2. Connectez-vous à la base de données source sur AWS à l'aide de SSMS.

3. Exécutez la commande T-SQL suivante pour créer le point de terminaison du groupe de disponibilité.

   USE [master]
   GO
   CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS
   GO
   
   USE [DATABASE_NAME]
   GO
   CREATE USER [NET_DOMAIN\sql_server] FOR LOGIN [NET_DOMAIN\sql_server]
   GO
   
   USE [master]
   GO
   CREATE ENDPOINT migration_endpoint
       STATE=STARTED
       AS TCP (LISTENER_PORT=5022)
       FOR DATABASE_MIRRORING (ROLE=ALL);
   GO
   
   GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server]
   GO
   

   Remplacez NET_DOMAIN par le nom NetBIOS de votre domaine AD et DATABASE_NAME par le nom de la base de données à migrer.

4. Connectez-vous au SQL Server de destination sur Google Cloud à l'aide de SSMS et exécutez la commande T-SQL suivante pour créer le point de terminaison de mise en miroir de la base de données.

   CREATE LOGIN [NET_DOMAIN\sql_server] FROM WINDOWS
   GO
   
   CREATE ENDPOINT migration_endpoint
       STATE=STARTED
       AS TCP (LISTENER_PORT=5022)
       FOR DATABASE_MIRRORING (ROLE=ALL);
   GO
   
   GRANT CONNECT ON ENDPOINT::[migration_endpoint] TO [NET_DOMAIN\sql_server]
   GO
   

   Remplacez NET_DOMAIN par le nom NetBIOS de votre domaine AD.

5. Vérifiez les points de terminaison en accédant à Server Objects > Endpoints > Mirroring Database (Objets de serveur > Points de terminaison > Mirroring de base de données) dans l'explorateur d'objets de SSMS.

   

Créer l'AOAG

Pour créer un AOAG, procédez comme suit:

1. Connectez-vous à la base de données source sur AWS à l'aide de SSMS.

2. Exécutez la commande T-SQL suivante pour définir le mode de récupération de la base de données sur "full" et effectuer une sauvegarde complète.

   USE [master]
   GO
   
   ALTER DATABASE [DATABASE_NAME]
   SET RECOVERY FULL;
   BACKUP DATABASE [DATABASE_NAME]
   TO DISK = N'C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Backup\DATABASE_NAME.bak';
   

   Remplacez DATABASE_NAME par le nom de la base de données à migrer.

3. Exécutez la commande T-SQL suivante pour créer l'AOAG.

   USE [master]
   GO
   
   CREATE AVAILABILITY GROUP [migration-ag]
   WITH (
       AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
       DB_FAILOVER = OFF,
       DTC_SUPPORT = NONE,
       REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0
   )
   FOR DATABASE [DATABASE_NAME]
   REPLICA ON
   N'SOURCE_SERVERNAME' WITH (
       ENDPOINT_URL = 'TCP://SOURCE_HOSTNAME:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       BACKUP_PRIORITY = 50,
       SEEDING_MODE = AUTOMATIC,
       SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
   ),
   N'DEST_SERVERNAME' WITH (
       ENDPOINT_URL = 'TCP://DEST_HOSTNAME:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       BACKUP_PRIORITY = 50,
       SEEDING_MODE = AUTOMATIC,
       SECONDARY_ROLE(ALLOW_CONNECTIONS = READ_ONLY)
   );
   GO
   

   Remplacez les éléments suivants :

   • DATABASE_NAME:nom de la base de données à migrer.
   • SOURCE_SERVERNAME:avec le nom du serveur de la base de données source.
   • DEST_SERVERNAME:avec le nom du serveur de la base de données de destination.
   • SOURCE_HOSTNAME:avec le nom de domaine complet (FQDN) de la source.
   • DEST_HOSTNAME:avec le nom de domaine complet de la cible.

4. Exécutez la commande T-SQL suivante sur la base de données de destination pour l'ajouter à l'AOAG.

   USE [master]
   GO
   
   ALTER AVAILABILITY GROUP [migration-ag] JOIN WITH (CLUSTER_TYPE = EXTERNAL);
   ALTER AVAILABILITY GROUP [migration-ag] GRANT CREATE ANY DATABASE;
   GO
   

5. Vérifiez l'état de l'AOAG et de la base de données nouvellement créés dans l'explorateur d'objets ou en exécutant la commande T-SQL suivante.

   SELECT * FROM sys.dm_hadr_availability_group_states
   GO
   

   

L'AOAG SQL Server est maintenant configuré et continue de se synchroniser entre AWS et Google Cloud. L'étape suivante consiste à configurer un WSFC et un écouteur pour la haute disponibilité et la reprise après sinistre. Pour en savoir plus, consultez les articles Clustering de basculement Windows Server avec SQL Server et Qu'est-ce qu'un écouteur de groupe de disponibilité ?.

Migrer à l'aide de groupes de disponibilité distribués

Un groupe de disponibilité distribué est un type particulier de groupe de disponibilité qui couvre deux groupes de disponibilité distincts. Il est conçu pour fournir des fonctionnalités de haute disponibilité et de reprise après sinistre dans des emplacements géographiquement dispersés. Cette architecture permet une réplication et un basculement fluides des données entre les groupes de disponibilité principal et secondaire, ce qui est idéal pour la migration de données. Pour en savoir plus, consultez la section Groupes de disponibilité distribués.

Les sections suivantes expliquent comment migrer votre base de données SQL Server à l'aide de groupes de disponibilité distribués.

Avant de commencer

Assurez-vous de disposer d'un cluster de basculement Windows Server avec SQL Server utilisant un groupe de disponibilité avec un écouteur de nom de réseau virtuel (VNN) exécuté sur AWS.

Préparer l'environnement de destination

Pour préparer l'environnement de destination, procédez comme suit:

1. Pour configurer un WSFC avec SQL Server à l'aide d'un groupe de disponibilité utilisant un équilibreur de charge interne sur Google Cloud, consultez Configurer des groupes de disponibilité AlwaysOn SQL Server avec commit synchrone à l'aide d'un équilibreur de charge interne.

2. Dans l'explorateur d'objets, vérifiez que bookshelf-ag a été créé et qu'il réplique la base de données bookshelf. Une fois la vérification effectuée, suivez les étapes suivantes pour supprimer le groupe de disponibilité et la base de données des deux nœuds de votre cluster de basculement.

   

3. Connectez-vous à node-1 dans SSMS et enregistrez l'adresse IP de l'écouteur bookshelf.

   SELECT * FROM sys.availability_group_listeners
   

4. Exécutez la commande T-SQL suivante pour supprimer le groupe de disponibilité bookshelf-ag et la base de données bookshelf.

   USE master
   GO
   
   DROP AVAILABILITY GROUP [bookshelf-ag]
   GO
   ALTER DATABASE [bookshelf] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   GO
   DROP DATABASE [bookshelf]
   GO
   

5. Exécutez le code T-SQL suivant sur node-2 dans SSMS pour supprimer la base de données répliquée.

   USE master
   GO
   
   DROP DATABASE [bookshelf]
   GO
   

Créer un groupe de disponibilité distribué

Pour créer un groupe de disponibilité à utiliser pour le groupe de disponibilité distribué, procédez comme suit:

1. Exécutez la commande T-SQL suivante sur node-1.

   USE master
   GO
   
   CREATE AVAILABILITY GROUP [gcp-dest-ag]
   FOR
   REPLICA ON
       N'NODE-1' WITH
       (
           ENDPOINT_URL = N'TCP://NODE-1:5022',
           FAILOVER_MODE = MANUAL,
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           BACKUP_PRIORITY = 50,
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
           SEEDING_MODE = AUTOMATIC
       ),
       N'NODE-2' WITH
       (
           ENDPOINT_URL = N'TCP://NODE-2:5022',
           FAILOVER_MODE = MANUAL,
           AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
           BACKUP_PRIORITY = 50,
           SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),
           SEEDING_MODE = AUTOMATIC
       );
   GO
   

2. Créez un écouteur.

   USE master;
   GO
   
   ALTER AVAILABILITY GROUP [gcp-dest-ag]
   ADD LISTENER N'gcp-dest-lsnr' (
   WITH IP (
   (N'LISTENER_IP', N'255.255.255.0')
   ),
   PORT = 1433);
   GO
   

   Remplacez LISTENER_IP par l'adresse IP de l'écouteur.

3. Connectez-vous à node-2 à l'aide de SSMS et exécutez la commande T-SQL suivante pour l'ajouter au groupe de disponibilité gcp-dest-ag.

   USE master
   GO
   
   ALTER AVAILABILITY GROUP [gcp-dest-ag] JOIN;
   ALTER AVAILABILITY GROUP [gcp-dest-ag] GRANT CREATE ANY DATABASE;
   

4. Connectez-vous au réplica principal du SQL Server source sur AWS à l'aide de SSMS, puis exécutez la commande T-SQL suivante pour créer un groupe de disponibilité distribué.

   USE [master]
   GO
   
   CREATE AVAILABILITY GROUP [distributed-ag]
   WITH (DISTRIBUTED)
   AVAILABILITY GROUP ON
   'AWS_AG' WITH
   (
       LISTENER_URL = 'tcp://AWS_LISTENER:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   ),
   'gcp-dest-ag' WITH
   (
       LISTENER_URL = 'tcp://gcp-dest-lsnr:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   )
   GO
   

   Remplacez AWS_AG par le nom du groupe de disponibilité dans AWS et AWS_LISTENER par l'écouteur du groupe de disponibilité AWS.

5. Exécutez la commande T-SQL suivante dans SSMS sur node-1 pour l'ajouter au groupe de disponibilité distribué.

   USE [master]
   GO
   
   ALTER AVAILABILITY GROUP [distributed-ag]
   JOIN
   AVAILABILITY GROUP ON
   'AWS_AG' WITH
   (
       LISTENER_URL = 'tcp://AWS_LISTENER:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   ),
   'gcp-dest-ag' WITH
   (
       LISTENER_URL = 'tcp://gcp-dest-lsnr:5022',
       AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
       FAILOVER_MODE = MANUAL,
       SEEDING_MODE = AUTOMATIC
   )
   GO
   

   Remplacez AWS_AG par le nom du groupe de disponibilité dans AWS et AWS_LISTENER par l'écouteur du groupe de disponibilité AWS.

6. Exécutez la commande T-SQL suivante sur "node-1" pour vérifier que tous les groupes de disponibilité sont opérationnels et qu'ils se répliquent entre le groupe de disponibilité distribué et le nouveau cluster SQL Server sur Google Cloud

   SELECT * FROM sys.dm_hadr_availability_group_states
   GO