Lien de basculement - Azure SQL Managed Instance

S’applique à : Azure SQL Managed Instance

Cet article vous apprend comment basculer une base de données liée entre SQL Server et Azure SQL Managed Instance en utilisant SQL Server Management Studio (SSMS) ou PowerShell.

Remarque

• La configuration d'Azure SQL Managed Instance comme instance principale initiale est actuellement en aperçu et n'est prise en charge qu'à partir de SQL Server 2022 CU10.

Prérequis

Pour basculer vos bases de données sur votre réplica secondaire via la liaison, vous devez disposer des conditions préalables suivantes :

• Un abonnement Azure actif. Si vous n’en avez pas, créez un compte gratuit.
• Version prise en charge de SQL Server avec la mise à jour de service requise installée.
• Liaison configurée entre votre réplica principal et secondaire.

Arrêter la charge de travail

Si vous êtes prêt à basculer votre base de données vers le réplica secondaire, arrêtez d'abord toutes les charges de travail des applications sur le réplica principal pendant les heures de maintenance. Cela permet à la réplication de la base de données de rattraper le retard sur le réplica secondaire afin que vous puissiez basculer vers le réplica secondaire sans perte de données. Assurez-vous que vos applications n'engagent pas de transactions sur le réplica principal avant de basculer.

Basculer une base de données

Vous pouvez basculer une base de données liée à l’aide de SQL Server Management Studio ou de PowerShell.

SQL Server Management Studio (SSMS)

Utilisez l'Assistant Basculement entre SQL Server et Managed Instance dans SSMS pour basculer votre base de données de votre réplica principal vers votre réplica secondaire.

Vous pouvez effectuer un basculement planifié à partir du réplica principal ou du réplica secondaire. Pour effectuer un basculement forcé, connectez-vous au réplica secondaire.

Attention

• Avant de basculer, arrêtez la charge de travail sur la base de données source pour permettre à la base de données répliquée de rattraper complètement son retard et de basculer sans perte de données. Si vous effectuez un basculement forcé, vous risquez de perdre des données.
• Le basculement d'une base de données dans SQL Server 2019 et les versions antérieures rompt et supprime la liaison entre les deux réplicas. Vous ne pouvez pas effectuer de retour vers le réplica principal initial.
• Le basculement d 'une base de données lors de la maintenance de la liaison avec SQL Server2022 est actuellement en aperçu.

Pour basculer votre base de données, procédez comme suit :

1. Ouvrez SSMS et connectez-vous à un réplica.

2. Dans Explorateur d'objets, faites un clic droit sur votre base de données répliquée, passez sur Liaison Azure SQL Managed Instance, puis sélectionnez Basculement… pour ouvrir l'Assistant Basculement entre SQL Server et Managed Instance. Si vous disposez de plusieurs liaisons à partir de la même base de données, développez Groupes de disponibilité sous Groupes de disponibilité Always On dans Explorateur d'objets et faites un clic droit sur le groupe de disponibilité distribué pour la liaison que vous souhaitez basculer. Sélectionnez Basculement... pour ouvrir l'Assistant Basculement entre SQL Server et Managed Instance pour cette liaison spécifique.

   

3. Dans la page Introduction, sélectionnez Suivant.

4. La page Choisir un type de basculement affiche des détails sur chaque réplica, le rôle de la base de données que vous avez sélectionnée et les types de basculement pris en charge. Vous pouvez initier le basculement à partir de n'importe quel réplica. Si vous choisissez un basculement forcé, vous devez cocher la case pour indiquer que vous comprenez qu'il peut y avoir une perte de données. Cliquez sur Suivant.

   Remarque

   Si vous migrez vers Azure SQL Managed Instance, choisissez Basculement planifié.

5. Dans la page Se connecter à Azure et à l’instance distante :

   1. Sélectionnez Se connecter pour fournir vos informations d’identification et vous connecter à votre compte Azure.
   2. En fonction du type de basculement sélectionné sur la page précédente, l’option Se connecter fonctionne différemment. Pour un basculement planifié, la connexion à l’instance distante (SQL Server ou SQL Managed Instance) est obligatoire. Pour un basculement forcé, la signature est facultative, car les deux scénarios suivants sont pris en charge :
      • Vraie récupération d'urgence : étant donné que l’instance principale n’est généralement pas disponible lors d’une vraie urgence, la connexion n’est pas possible et l’utilisateur doit basculer immédiatement vers l’instance secondaire, ce qui en fait la nouvelle instance principale. Une fois la panne résolue, le lien est dans un état incohérent, car les deux réplicas se trouvent désormais dans le rôle principal (scénario fractionné-cerveau).
      • Exercice de récupération d'urgence : l’exécution d’exercices de récupération d'urgence avec basculement forcé est déconseillée, car il peut y avoir une perte de données potentielle. Toutefois, pendant un exercice, étant donné que l’instance principale est disponible, la connexion est prise en charge et vous avez la possibilité d’inverser les rôles pour les deux réplicas afin d’éviter le scénario de fractionnement du cerveau.

6. Dans la page Opérations post-basculement, les options diffèrent entre SQL Server 2022 et versions antérieures, et indiquez si vous avez pu vous connecter à l’instance principale ou non.

   • Pour SQL Server 2022, vous pouvez choisir d'arrêter la réplication entre les répliques, ce qui supprime la liaison et le groupe de disponibilité distribué une fois le basculement terminé. Si vous souhaitez maintenir la liaison et continuer à répliquer les données entre les réplicas, ne cochez pas la case. Si vous choisissez de supprimer la liaison, vous pouvez également cocher la case pour supprimer le groupe de disponibilité si vous l'avez créé uniquement dans le but de répliquer votre base de données sur Azure et que vous n'en avez plus besoin. Cochez les cases correspondant à votre scénario, puis sélectionnez Suivant.
   • Pour SQL Server 2019 et les versions antérieures, l'option Supprimer la liaison est cochée par défaut, et vous ne pouvez pas la décocher car le basculement vers SQL Managed Instance arrête la réplication, rompt la liaison et supprime le groupe de disponibilité distribué. Cochez la case pour indiquer que vous comprenez que la liaison sera supprimée, puis sélectionnez Suivant.
   • (Facultatif) Si vous avez pu vous connecter à l’instance SQL Server sur la page précédente, vous avez également la possibilité de supprimer le groupe de disponibilité sur l’instance SQL Server après un basculement forcé en cochant la case dans la section Nettoyage.

7. Évaluez les actions sur la page Résumé. Si vous le souhaitez, sélectionnez Script pour générer un script qui vous permettra de basculer facilement la base de données en utilisant la même liaison à l'avenir. Sélectionnez Terminer lorsque vous êtes prêt à basculer la base de données.

8. Une fois toutes les étapes terminées, la page Résultats affiche des coches en regard des actions accomplies avec succès. Vous pouvez à présent fermer la fenêtre.

Si vous avez choisi de maintenir la liaison pour SQL Server 2022, le réplica secondaire devient le nouveau réplica principal, la liaison reste active et vous pouvez basculer vers le réplica secondaire.

Si vous utilisez SQL Server 2019 et les versions antérieures, ou si vous avez choisi de supprimer la liaison pour SQL Server 2022, cette liaison est supprimée et n'existe plus une fois le basculement terminé. La base de données source et la base de données cible de chaque réplica peuvent toutes deux exécuter une charge de travail en lecture/écriture. Elles sont totalement indépendantes.

Important

Après le basculement réussi vers la SQL Managed Instance, reportez manuellement la chaîne de connexion de votre (vos) application(s) vers le FQDN de SQL Managed Instance pour terminer le processus de migration ou de basculement et continuer l'exécution dans Azure.

PowerShell

Pour basculer, vous devez d’abord basculer les modes de réplication de l’instance SQL Server à l’aide de Transact-SQL (T-SQL).

Vous pouvez ensuite basculer et changer de rôle à l’aide de PowerShell.

Basculez le mode de réplication (basculement vers SQL MI)

La réplication entre SQL Server et SQL Managed Instance est asynchrone par défaut. Si vous basculez de SQL Server vers Azure SQL Managed Instance, avant de basculer votre base de données, basculez le lien vers le mode synchrone sur SQL Server à l’aide de Transact-SQL (T-SQL).

Remarque

• Ignorez cette étape si vous passez de SQL Managed Instance vers SQL Server 2022.
• La réplication synchrone sur de grandes distances de réseau peut ralentir les transactions sur le réplica principal.

Exécutez le script T-SQL suivant sur SQL Server pour changer le mode de réplication du groupe de disponibilité distribué en passant du mode asynchrone au mode synchrone. Remplacez :

• <DAGName> par le nom du groupe de disponibilité distribué (utilisé pour créer le lien).
• <AGName> par le nom du groupe de disponibilité créé sur SQL Server (utilisé pour créer le lien).
• <ManagedInstanceName> par le nom de votre instance managée.

-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Pour confirmer que vous avez correctement changé le mode de réplication de la liaison, utilisez la vue de gestion dynamique suivante. Les résultats indiquent l’état SYNCHRONOUS_COMMIT.

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

Maintenant que vous avez basculé SQL Server en mode de validation synchrone, la réplication entre les deux instances est synchrone. Si vous devez inverser cet état, suivez les mêmes étapes et définissez AVAILABILITY_MODE sur ASYNCHRONOUS_COMMIT.

Vérifiez les valeurs LSN sur SQL Server et SQL Managed Instance

Pour terminer le basculement ou la migration, confirmez que la réplication vers le secondaire est terminée. Pour ce faire, vérifiez que les numéros séquentiels dans le journal (LSN) correspondant aux enregistrements du journal de SQL Server et SQL Managed Instance sont identiques.

Il est prévu initialement que, le LSN du réplica principal soit plus élevé que celui du réplica secondaire. Le temps de réponse du réseau peut entraîner un certain décalage de la réplication par rapport au réplica principal. Comme la charge de travail a été arrêtée sur le principal, les LSN correspondront et cesseront de changer après un certain temps.

Utilisez la requête T-SQL suivante sur SQL Server pour lire le LSN du dernier journal des transactions enregistré. Remplacez :

• <DatabaseName> par le nom de votre base de données et recherchez le dernier numéro LSN renforcé.

-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

Utilisez la requête T-SQL suivante sur SQL Managed Instance pour lire le dernier numéro LSN renforcé pour votre base de données. Remplacez <DatabaseName> par le nom de votre base de données.

Cette requête fonctionne sur une SQL Managed Instance à usage général. Pour une SQL Managed Instance critique pour l'entreprise, supprimez les marques de commentaire and drs.is_primary_replica = 1 à la fin du script. Sur le niveau de service critique pour l'entreprise, ce filtre garantit que les détails ne sont lus qu'à partir du réplica principal.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

Vous pouvez également utiliser la commande Get-AzSqlInstanceLink PowerShell ou Afficher la liaison az sql mi Azure CLI pour récupérer la propriété LastHardenedLsn de votre liaison sur SQL Managed Instance afin de fournir les mêmes informations que la requête T-SQL précédente.

Important

Vérifiez à nouveau que votre charge de travail est arrêtée sur le réplica principal. Vérifiez que les LSN sur SQL Server et SQL Managed Instance correspondent, et qu’ils restent identiques et inchangés pendant un certain temps. Des LSN stables sur les deux instances indiquent que le fichier journal d'activité a été répliqué sur le réplica secondaire et que la charge de travail est effectivement arrêtée.

Basculer une base de données

Si vous souhaitez utiliser PowerShell pour basculer une base de données entre SQL Server 2022 et SQL Managed Instance tout en maintenant la liaison, ou pour effectuer un basculement avec perte de données pour n'importe quelle version de SQL Server, utilisez l'Assistant Basculement entre SQL Server et Managed Instance dans SSMS pour générer le script pour votre environnement. Vous pouvez effectuer un basculement planifié à partir du réplica principal ou du réplica secondaire. Pour effectuer un basculement forcé, connectez-vous au réplica secondaire.

Pour rompre la liaison et arrêter la réplication en cas de basculement ou de migration de votre base de données, quelle que soit la version de SQL Server, utilisez la commande Remove-AzSqlInstanceLink PowerShell ou Supprimer la liaison az sql mi Azure CLI.

Attention

• Avant de basculer, arrêtez la charge de travail sur la base de données source pour permettre à la base de données répliquée de rattraper complètement son retard et de basculer sans perte de données. Si vous effectuez un basculement forcé ou si vous arrêtez la liaison avant la correspondance des LSN, vous risquez de perdre des données.
• Le basculement d'une base de données dans SQL Server 2019 et les versions antérieures rompt et supprime la liaison entre les deux réplicas. Vous ne pouvez pas effectuer de retour vers le réplica principal initial.
• Le basculement d 'une base de données lors de la maintenance de la liaison avec SQL Server2022 est actuellement en aperçu.

L'exemple de script suivant rompt la liaison et met fin à la réplication entre vos réplicas, en mettant la base de données en lecture/écriture sur les deux instances. Remplacez :

• <ManagedInstanceName> par le nom de votre instance managée.
• <DAGName> par le nom du lien vers lequel vous basculez (sortie de la propriété Name à partir de la commande Get-AzSqlInstanceLink exécutée précédemment ci-dessus).

# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

Après le processus de basculement, la liaison est supprimée et n’existe plus. La base de données SQL Server et la base de données SQL Managed Instance peuvent toutes deux exécuter des charges de travail en lecture et en écriture car elles sont désormais complètement indépendantes.

Important

Après le basculement réussi vers la SQL Managed Instance, reportez manuellement la chaîne de connexion de votre (vos) application(s) vers le FQDN de SQL Managed Instance pour terminer le processus de migration ou de basculement et continuer l'exécution dans Azure.

Une fois le lien supprimé, vous pouvez conserver le groupe de disponibilité sur SQL Server, mais vous devez supprimer le groupe de disponibilité distribué pour supprimer les métadonnées de lien de SQL Server. Cette étape supplémentaire n’est nécessaire que lorsque vous basculez à l’aide de PowerShell, car SSMS effectue cette action pour vous.

Pour supprimer votre groupe de disponibilité distribué, remplacez la valeur suivante, puis exécutez l’exemple de code T-SQL :

• <DAGName> par le nom du groupe de disponibilité distribué sur SQL Server (utilisé pour créer le lien).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

Afficher la base de données après le basculement

Pour SQL Server 2022, si vous avez choisi de conserver le lien, vous pouvez vérifier que le groupe de disponibilité distribué existe sous Groupes de disponibilité dans l’Explorateur d'objets dans SQL Server Management Studio.

Si vous avez supprimé la liaison pendant le basculement, vous pouvez utiliser l'Explorateur d'objets pour confirmer que le groupe de disponibilité distribué n'existe plus. Si vous avez choisi de conserver le groupe de disponibilité, la base de données sera toujours Synchronisée.

Nettoyer les groupes de disponibilité

Étant donné que le basculement avec SQL Server 2022 n’interrompt pas le lien, vous pouvez conserver le lien après le basculement, ce qui laisse le groupe de disponibilité et le groupe de disponibilité distribué actif. Aucune action supplémentaire n’est requise.

Toutefois, la suppression du lien supprime uniquement le groupe de disponibilité distribué et laisse le groupe de disponibilité actif. Vous pouvez décider de conserver le groupe de disponibilité ou de le supprimer.

Si vous décidez de supprimer votre groupe de disponibilité, remplacez la valeur suivante, puis exécutez l’exemple de code T-SQL :

• <AGName> par le nom du groupe de disponibilité sur SQL Server (utilisé pour créer le lien).

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Contenu connexe

Pour en savoir plus sur la fonctionnalité de liaison, évaluez les ressources suivantes :

• Liaison Managed Instance – Vue d'ensemble
• Préparer votre environnement pour une liaison Managed Instance
• Configurer la liaison entre SQL Server et SQL Managed Instance avec les scripts
• Récupération d’urgence avec la liaison Managed Instance
• Meilleures pratiques pour préserver la liaison