Dans SQL Server, la haute disponibilité est cruciale pour garantir un accès ininterrompu aux données et minimiser les temps d’arrêt. L’une des façons d’atteindre une haute disponibilité est de passer par le clustering, en utilisant spécifiquement la fonction Always On. Le clustering consiste à créer une collection logique de deux serveurs physiques ou plus (nœuds) qui hébergent individuellement des instances SQL et ont accès à un stockage partagé.
Lorsque les applications se connectent à un cluster, elles ne se connectent pas aux instances SQL individuelles, mais plutôt au cluster lui-même. Cela permet une bascule automatique vers un nœud secondaire si le nœud principal devient indisponible en raison de problèmes quelconques. Les utilisateurs ou les applications ne subiront aucune perte de données ni aucun temps d’arrêt pendant ce processus de bascule.
Cependant, il existe certains objets, tels que les connexions, les autorisations et les tâches, qui doivent être configurés sur chaque nœud individuel du cluster. Cela peut poser un défi en ce qui concerne l’exécution des tâches sur les nœuds secondaires.
Lorsque le nœud principal est utilisé, les nœuds secondaires ne sont pas accessibles pour les opérations d’écriture. Si vous essayez d’accéder à une base de données sur un nœud secondaire, vous rencontrerez une erreur. Cela peut poser problème pour les tâches programmées sur le nœud secondaire, car elles peuvent échouer et envoyer des notifications d’échec ou des tickets de support.
Pour résoudre ce problème, il existe deux solutions possibles :
1. Planificateur externe
Une option consiste à utiliser des planificateurs externes tels que BMC Control-M ou UC4 Automic, ou des planificateurs de base inclus dans le système d’exploitation. Ces planificateurs externes peuvent exécuter un script directement sur le cluster. Cependant, cette approche peut être coûteuse car elle nécessite des licences et une maintenance supplémentaires.
2. Vérification explicite sur le nœud
La deuxième solution consiste à ajouter des étapes supplémentaires aux tâches programmées sur le nœud secondaire. Ces étapes vérifieront si le nœud sur lequel la tâche est exécutée est le nœud principal ou non. S’il s’agit du nœud principal, la tâche passera aux étapes suivantes. S’il ne s’agit pas du nœud principal, une erreur sera générée (non fatale) et la tâche passera à la dernière étape. Dans la dernière étape, l’exception sera gérée et la tâche se terminera en signalant son succès. Cela garantit qu’aucune fausse alarme n’est déclenchée dans les notifications.
Voici un exemple de mise en œuvre de cette solution :
IF
(
SELECT ars.role_desc
FROM sys.dm_hadr_availability_replica_states ars
INNER JOIN sys.availability_groups ag
ON ars.group_id = ag.group_id
WHERE ag.NAME = 'NOM_DU_CLUSTER'
AND ars.is_local = 1) != 'PRIMARY'
BEGIN
RAISERROR (N'Ceci est une base de données secondaire', 11,1);
END
ELSE
BEGIN
PRINT 1
END
Tout d’abord, créez une étape de tâche et faites-en la première étape de la tâche. Ajoutez le script ci-dessus à la fenêtre de commande de cette étape. Ce script vérifie si le nœud actuel est le nœud principal ou non.
Ensuite, ajoutez les étapes de tâche supplémentaires nécessaires pour effectuer votre logique.
Enfin, ajoutez une nouvelle étape et déplacez-la en dernière position de la tâche. Configurez-la comme suit :
- Accédez à l’étape 1 et sélectionnez la page avancée.
- Sélectionnez “Aller à l’étape : Gérer l’exception du nœud principal” dans la liste déroulante Action en cas d’échec.
- Sélectionnez “Aller à l’étape suivante” dans la liste déroulante Action en cas de réussite.
- Accédez à la dernière étape et sélectionnez la page avancée.
- Sélectionnez “Quitter la tâche en signalant le succès” pour les listes déroulantes Action en cas de réussite et Action en cas d’échec.
Assurez-vous de suivre ces étapes à la fois sur les nœuds principal et secondaire. Cela garantit que les scripts de tâche réels ne s’exécutent que sur le serveur principal et qu’aucune fausse alarme n’est signalée.
En mettant en œuvre cette solution, vous pouvez vous assurer que les tâches programmées sur le nœud secondaire ne déclenchent pas de notifications ou de tickets de support inutiles. Cela contribue à maintenir un environnement de haute disponibilité fluide et efficace dans SQL Server.