Changer le cluster qui gère les métadonnées pour les réplicas dans un groupe de disponibilité Always On

S’applique à : SQL Server - Windows uniquement

Cette rubrique explique comment basculer le contexte de cluster HADR d’une instance de SQL Server en utilisant Transact-SQL dans SQL Server 2012 SP1 (11.0.3x) et versions ultérieures. Le contexte de cluster HADR détermine le cluster de clustering de basculement Windows Server (WSFC) qui gère les métadonnées pour les réplicas de disponibilité hébergés par l’instance de serveur.

Basculez le contexte de cluster HADR uniquement pendant une migration entre clusters de Groupes de disponibilité Always On vers une instance de SQL Server 2012 SP1 (11.0.3x) sur un nouveau cluster WSFC. La migration entre clusters de Groupes de disponibilité Always On prend en charge la mise à niveau vers Windows 8 ou Windows Server 2012 avec un temps mort minimal des groupes de disponibilité. Pour plus d’informations, consultez Migration entre clusters de groupes de disponibilité Always On pour la mise à niveau du système d’exploitation.

Limitations et restrictions

• Vous pouvez basculer le contexte de cluster HADR uniquement du cluster WSFC local vers un cluster distant, puis de nouveau du cluster distant vers le cluster local. Vous ne pouvez pas changer de contexte de cluster HADR d'un cluster distant à un autre.

• Il est possible de basculer le contexte de cluster HADR vers un cluster distant uniquement lorsque l'instance de SQL Server n'héberge pas un réplica de disponibilité.

• Un environnement de cluster HADR distant peut être basculé vers le cluster local à tout moment. Toutefois, le contexte ne peut pas être rebasculé tant que l'instance de serveur héberge des réplicas de disponibilité.

Prérequis

• L'instance de serveur sur laquelle vous modifiez le contexte de cluster HADR doit exécuter SQL Server 2012 SP1 (11.0.3x) ou version ultérieure (édition Entreprise ou ultérieure).

• L’instance de serveur doit être activée pour Always On. Pour plus d’informations, consultez Activer et désactiver les groupes de disponibilité Always On (SQL Server).

• Pour pouvoir être basculée du contexte de cluster local vers un cluster à distance, une instance de serveur ne peut pas héberger de réplicas de disponibilité. La vue de catalogue sys.availability_replicas ne doit retourner aucune ligne.

  S'il existe des réplicas de disponibilité sur l'instance de serveur, avant de modifier le contexte de cluster HADR, vous devez effectuer l'une des opérations suivantes :

  Rôle du réplica	Action	Lien
  Principal	Place le groupe de disponibilité hors connexion.	Placer un groupe de disponibilité hors connexion (SQL Server)
  Secondary	Supprimer le réplica de son groupe de disponibilité	Supprimer un réplica secondaire d'un groupe de disponibilité (SQL Server)

• Avant de pouvoir basculer d'un cluster à distance vers un cluster local, tous les réplicas de validation synchrone doivent être dans l'état SYNCHRONIZED.

Recommandations

• Nous vous recommandons de spécifier le nom de domaine complet. Cela est dû au fait que pour rechercher l'adresse IP cible d'un nom court, ALTER SERVER CONFIGURATION utilise la résolution DNS. Dans certaines situations, selon l'ordre de recherche de DNS, l'utilisation d'un nom court peut entraîner quelques confusions. Par exemple, considérez la commande suivante, exécutée sur un nœud dans le domaine abc , (node1.abc.com). Le cluster de destination attendu est le cluster CLUS01 dans le domaine xyz (clus01.xyz.com). Toutefois, le domaine local héberge aussi un cluster nommé CLUS01 (clus01.abc.com).

  Si le nom court du cluster cible, CLUS01, a été spécifié, la résolution de noms DNS peut retourner l'adresse IP d'un cluster incorrect, clus01.abc.com. Pour éviter une telle confusion, spécifiez le nom complet du cluster cible, comme dans l'exemple suivant :

  ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT = 'clus01.xyz.com'  
  

Autorisations

• compte de connexion SQL Server

  Requiert l'autorisation CONTROL SERVER.

• Compte de service SQL Server

  Le compte de service SQL Server de l'instance de serveur doit disposer :

  • des autorisations nécessaires pour ouvrir le cluster WSFC de destination ;

  • d'un accès en lecture/écriture au cluster WSFC distant.

Utilisation de Transact-SQL

Pour modifier le contexte de cluster WSFC d'un réplica de disponibilité

1. Connectez-vous à l'instance de qui héberge soit le réplica principal, soit un réplica secondaire du groupe de disponibilité.

2. Utilisez la clause SET HADR CLUSTER CONTEXT de l’instruction ALTER SERVER CONFIGURATION , comme suit :

   ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT = { 'windows_cluster' | LOCAL }

   où :

   windows_cluster
   Le nom d'objet cluster (CON) d'un cluster WSFC. Vous pouvez spécifier le nom court ou le nom de domaine complet. Nous vous recommandons de spécifier le nom de domaine complet. Pour plus d'informations, consultez Recommandations, plus haut dans cette rubrique.

   LOCAL
   Cluster WSFC local

Exemples

L'exemple qui suit remplace le contexte de cluster HADR par un autre cluster. Pour identifier le cluster WSFC de destination, clus01, l'exemple spécifie le nom d'objet cluster complet, clus01.xyz.com.

ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT = 'clus01.xyz.com';  

L'exemple qui suit remplace le contexte de cluster HADR par le cluster WSFC local.

ALTER SERVER CONFIGURATION SET HADR CLUSTER CONTEXT = LOCAL;  

Suivi : après le basculement du contexte de cluster d'un réplica de disponibilité

Le nouveau contexte de cluster HADR prend effet immédiatement, sans redémarrer l'instance de serveur. Le paramètre de contexte de cluster HADR est un paramètre persistant au niveau de l'instance qui demeure inchangé si l'instance de serveur redémarre.

Confirmez le nouveau contexte de cluster HADR en interrogeant la vue de gestion dynamique sys.dm_hadr_cluster , comme suit :

SELECT cluster_name FROM sys.dm_hadr_cluster  

Cette requête doit retourner le nom du cluster auquel sur lequel vous définissez le contexte de cluster HADR.

Lorsque le contexte de cluster HADR est basculé vers un nouveau cluster :

• Les métadonnées sont nettoyées pour tous les réplicas de disponibilité qui sont actuellement hébergés par l'instance de SQL Server.

• Toutes les bases de données qui ont déjà appartenu à un réplica de disponibilité sont désormais dans un état RESTORING.

Tâches associées

• Supprimer un écouteur de groupe de disponibilité (SQL Server)

• Placer un groupe de disponibilité hors connexion (SQL Server)

• Ajouter un réplica secondaire à un groupe de disponibilité (SQL Server)

• Supprimer un réplica secondaire d'un groupe de disponibilité (SQL Server)

• Créer ou configurer un écouteur de groupe de disponibilité (SQL Server)

• Joindre une base de données secondaire à un groupe de disponibilité (SQL Server)

Contenu associé

• Articles techniques SQL Server 2012

• Blog de l’équipe SQL Server Always On : Blog officiel de l’équipe SQL Server Always On

Voir aussi

Groupes de disponibilité SQL Server Always On (SQL Server)
Clustering de basculement Windows Server (WSFC) avec SQL Server
ALTER SERVER CONFIGURATION (Transact-SQL)