Lien de basculement - Azure SQL Managed Instance

  • Article

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 à des fins de récupération après sinistre ou de migration.

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 :

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 en utilisant Transact-SQL (T-SQL), SQL Server Management Studio ou PowerShell.

Vous pouvez basculer le lien en utilisant Transact-SQL à partir de SQL Server 2022 CU13 (KB5036432).

Pour effectuer un basculement planifié pour un lien, utilisez la commande T-SQL suivante sur le réplica principal :

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Pour effectuer un basculement forcé, utilisez la commande T-SQL suivante sur le réplica secondaire :

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

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 après le basculement

Sauf si Supprimer la liaison après un basculement réussi est sélectionné, un basculement avec SQL Server 2022 n’interrompt pas la liaison. Vous pouvez conserver la liaison après le basculement, ce qui laisse le groupe de disponibilité et le groupe de disponibilité distribué actifs. Aucune action supplémentaire n’est requise.

La suppression de la liaison 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

État incohérent après le basculement forcé

Après un basculement forcé, vous pouvez rencontrer un scénario fractionné dans lequel les deux réplicas ont le rôle principal, laissant la liaison dans un état incohérent. Cela peut se produire si vous basculez vers le réplica secondaire lors d’une urgence, puis que le réplica principal revient en ligne.

Tout d’abord, vérifiez que vous êtes dans un scénario fractionné. Vous pouvez le faire à l’aide de SQL Server Management Studio (SSMS) ou de Transact-SQL (T-SQL).

Connectez-vous à SQL Server et à SQL Managed Instance dans SSMS, puis dans l’Explorateur d’objets, développez les réplicas de disponibilité sous le nœud du groupe de disponibilité dans Haute disponibilité Always-on. Si deux réplicas différents sont répertoriés en tant que (Principal), vous êtes dans un scénario fractionné.

Vous pouvez également exécuter le script T-SQL suivant sur SQL Server et SQL Managed Instance pour vérifier le rôle des réplicas :

-- Execute on SQL Server and SQL Managed Instance 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

Si les deux instances répertorient un Principal différent dans la colonne Rôle de la liaison, vous êtes dans un scénario fractionné.

Pour résoudre l’état fractionné, commencez par effectuer une sauvegarde sur le réplica qui était le réplica principal d’origine. Si le réplica principal d’origine était SQL Server, effectuez une sauvegarde de la fin du journal. Si le réplica principal d’origine était SQL Managed Instance, effectuez une sauvegarde complète de copie uniquement. Une fois la sauvegarde terminée, définissez le groupe de disponibilité distribué sur le rôle secondaire pour le réplica qui était le réplica principal d’origine, mais sera désormais le nouveau réplica secondaire.

Par exemple, en cas d’urgence véritable, en supposant que vous avez forcé un basculement de votre charge de travail SQL Server vers Azure SQL Managed Instance et que vous envisagez de continuer à exécuter votre charge de travail sur SQL Managed Instance, effectuez une sauvegarde de la fin du journal sur SQL Server, puis définissez le groupe de disponibilité distribué sur le rôle secondaire sur SQL Server, comme dans l’exemple suivant :

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO

Ensuite, exécutez un basculement manuel programmé de SQL Managed Instance vers SQL Server à l’aide de la liaison, comme dans l’exemple suivant :

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO

Contenu connexe

Pour utiliser le lien :

Pour en savoir plus sur le lien :

Pour d’autres scénarios de réplication et de migration, considérez :