Récupération d'urgence WSFC par le quorum forcé (SQL Server)

  • Article

S'applique à : SQL Server

L'échec du quorum est généralement dû à un problème systémique grave, à un échec de communication persistant ou à une mauvaise configuration impliquant plusieurs nœuds dans le cluster WSFC. Une intervention manuelle est nécessaire pour la récupération d'une défaillance de quorum.

Avant de commencer

Prérequis

La procédure de quorum forcé suppose qu'un quorum sain existait avant l'échec de quorum.

Avertissement

L'utilisateur doit bien connaître les concepts et les interactions du clustering de basculement Windows Server, des modèles de quorum WSFC, de SQL Serveret de la configuration de déploiement spécifique à l'environnement.

Pour plus d’informations, consultez : Clustering de basculement Windows Server (WSFC) avec SQL Server, Modes de quorum de WSFC et configuration des votes (SQL Server).

Sécurité

L'utilisateur doit être un compte de domaine qui est membre du groupe Administrateurs local sur chaque nœud du cluster WSFC.

Récupération d'urgence WSFC par le quorum forcé

N'oubliez pas qu'un échec de quorum met hors ligne tous les services cluster, toutes les instances SQL Server et Groupes de disponibilité Always Ondans le cluster WSFC, car le cluster, tel que configuré, ne peut pas garantir la tolérance de panne au niveau du nœud. Un échec de quorum signifie que les nœuds votants sains dans le cluster WSFC ne satisfont plus le modèle de quorum. Certains nœuds ont peut-être échoué complètement, et d'autres ont peut-être simplement arrêté le service WSFC et sont sains par ailleurs, sauf en ce qui concerne la perte de la capacité de communiquer avec un quorum.

Pour remettre le cluster WSFC en ligne, vous devez corriger la cause première de l'échec de quorum dans la configuration existante, récupérer les bases de données concernées si nécessaire et, éventuellement, reconfigurer les nœuds restants dans le cluster WSFC pour refléter la topologie de cluster survivante.

Vous pouvez utiliser la procédure de quorum forcé sur un nœud de cluster WSFC pour remplacer les contrôles de sécurité qui ont mis le cluster hors connexion. Cela est efficace pour indiquer au cluster d'interrompre les contrôles de vote du quorum et vous permet de remettre en ligne les ressources du cluster WSFC et SQL Server sur tous les nœuds dans le cluster.

Ce type de processus de récupération d'urgence doit inclure les étapes suivantes :

Pour une récupération en cas d'échec de quorum :

  1. Déterminez l'étendue de l'échec. Identifiez les groupes de disponibilité ou les instances de SQL Server non sensibles et les nœuds du cluster qui sont en ligne et disponibles à l'utilisation post-incident, puis examinez les journaux des événements Windows et les journaux système de SQL Server. Si possible, vous devez conserver les données d'analyse et les journaux système pour les examiner ultérieurement.

    Conseil

    Sur une instance de SQL Serverqui répond, vous pouvez obtenir des informations sur l’état d’intégrité des groupes de disponibilité qui possèdent un réplica de disponibilité sur l’instance de serveur local en interrogeant la vue de gestion dynamique (DMV) sys.dm_hadr_availability_group_states .

  2. Démarrez le cluster WSFC en utilisant le quorum forcé sur un nœud unique. Identifiez un nœud avec un nombre minime de défaillances de composant, autre que celui qui a arrêté le service de cluster WSFC. Vérifiez que ce nœud peut communiquer avec la majorité des autres nœuds.

    Sur ce nœud, forcez manuellement la mise en ligne du cluster à l'aide de la procédure de quorum forcé. Pour réduire au minimum la perte de données, sélectionnez le dernier nœud qui hébergeait un réplica principal de groupe de disponibilité.

    Pour plus d’informations, consultez : Forcer un cluster WSFC à démarrer sans quorum

    Notes

    L'application d'un quorum forcé bloque les contrôles de quorum sur l'ensemble du cluster jusqu'à ce que le cluster WSFC logique atteigne une majorité des votes et passe automatiquement à un mode d'opération de quorum standard.

  3. Démarrez le service WSFC normalement sur chaque nœud par ailleurs sain, en procédant avec un nœud à la fois. Vous ne devez pas spécifier l'option de quorum forcé lorsque vous démarrez le service de cluster sur les autres nœuds.

    Lorsque le service WSFC revient en ligne sur chaque nœud, il négocie avec les autres nœuds sains pour synchroniser le nouvel état de configuration du cluster. N'oubliez pas d'effectuer ces opérations sur un nœud à la fois, afin d'éviter des conditions potentielles de concurrence lors de la résolution du dernier état connu du cluster.

    Avertissement

    Vérifiez que chaque nœud que vous démarrez peut communiquer avec les autres nœuds récemment mis en ligne. Éventuellement, désactivez le service WSFC sur les autres nœuds. Sinon, vous courez le risque de créer plusieurs ensembles de nœuds de quorum, c’est-à-dire un scénario « split-brain ». Si vos résultats à l'étape 1 étaient précis, cela ne devrait pas se produire.

  4. Appliquez le nouveau mode de quorum et la nouvelle configuration de vote des nœuds. Si l'application forcée d'un quorum a redémarré tous les nœuds du cluster et la cause première de l'échec de quorum a été corrigée, le mode de quorum d'origine et la configuration de vote des nœuds n'ont pas besoin d'être modifiés.

    Sinon, vous devez évaluer la topologie de nœud de cluster et de réplica de disponibilité nouvellement créée et modifier le mode de quorum et les affectations de vote pour chaque nœud, comme il convient. Les nœuds non récupérés doivent être mis hors connexion, ou bien leurs votes de nœud doivent être définis sur zéro.

    Conseil

    À ce stade, les nœuds et les instances de SQL Server dans le cluster peuvent apparaître comme restaurés et sembler fonctionner normalement. Toutefois, il est possible qu'il n'y ait pas encore de quorum sain. À l’aide du Gestionnaire du cluster de basculement, du Tableau de bord Always On dans SQL Server Management Studio ou des vues DMV appropriées, vérifiez qu’un quorum a été restauré.

  5. Récupérez les réplicas de base de données du groupe de disponibilité si nécessaire. Les bases de données qui n'appartiennent pas au groupe de disponibilité doivent être restaurées et remises en ligne au cours du processus de démarrage normal de SQL Server, sans autre intervention.

    Vous pouvez minimiser la perte potentielle de données et le temps de récupération pour les réplicas de groupe de disponibilité en les remettant en ligne dans cette séquence : réplica principal, réplicas secondaires synchrones, réplicas secondaires asynchrones.

Notes

Après l’utilisation du quorum forcé, il est nécessaire d’effectuer un basculement forcé avec un risque de perte de données pour remettre le groupe de disponibilité en ligne. Pour plus d’informations, consultez Effectuer un basculement manuel forcé d’un groupe de disponibilité (SQL Server).

  1. Réparez ou remplacez les composants en échec et re-validez le cluster. Maintenant que vous avez remédié au sinistre et à l’échec de quorum, vous devez réparer ou remplacer les nœuds en échec et modifier les configurations WSFC et Always On associées en conséquence. Cela peut inclure la suppression des réplicas de groupe de disponibilité, l'éviction des nœuds du cluster ou la mise à plat et la réinstallation des logiciels sur un nœud.

    Vous devez réparer ou supprimer tous les réplicas de disponibilité. SQL Server ne tronquera pas le journal des transactions après le dernier point connu du réplica de disponibilité le plus lointain. Si un réplica n'est pas réparé ou n'est pas supprimé du groupe de disponibilité, les journaux des transactions vont prendre du volume et vous allez courir le risque de manquer d'espace pour les autres réplicas.

    Notes

    Si vous exécutez l'Assistant WSFC Valider une configuration alors qu'un écouteur du groupe de disponibilité existe sur le cluster WSFC, l'Assistant génère le message d'avertissement incorrect suivant :

    « La propriété RegisterAllProviderIP du nom réseau ’Name:<nom_réseau>’ est définie sur 1. Pour la configuration de cluster actuelle, cette valeur doit être définie sur 0. »

    Veuillez ignorer ce message.

  2. Répétez l'étape 4 si nécessaire. L'objectif est de rétablir le niveau de la tolérance de panne approprié et une haute disponibilité pour des opérations saines.

  3. Effectuez une analyse RPO/RTO. Vous devez analyser les journaux système SQL Server, les horodateurs de base de données et les journaux des événements Windows pour déterminer la cause première de l'échec et pour documenter les expériences de point et de temps de récupération actuelles.

Tâches associées

Contenu associé

Voir aussi

Clustering de basculement Windows Server (WSFC) avec SQL Server