Comment corriger l’erreur “Groupe de disponibilité de base de données (DAG) doit avoir un Quorum” ?

Un groupe de disponibilité de base de données (DAG) est idéal pour le basculement et la haute disponibilité de votre serveur et de vos services Exchange. Bien qu’il s’agisse de la meilleure solution pour la continuité des activités et la récupération des données d’Exchange Server, vous pouvez rencontrer des problèmes imprévus susceptibles d’affecter les performances, la qualité et l’intégrité des données de l’infrastructure d’Exchange Server.

L’un des pires scénarios qu’un administrateur Exchange puisse rencontrer est le démontage d’une base de données de boîtes aux lettres. Si vous essayez de monter la base de données, l’erreur suivante peut se produire :

La base de données “DB01” n’a pas pu être montée. Erreur : Un processus Active Manager a échoué. Erreur : Une erreur s’est produite au cours d’une opération Active Manager. Pour effectuer cette opération, le serveur doit être membre d’un groupe de disponibilité de base de données et le groupe de disponibilité de base de données doit avoir un quorum. Erreur : Il n’est pas possible de lire la base de données du cluster.

Cela peut se produire si le serveur a été récemment supprimé du groupe de disponibilité de la base de données.

[Serveur : EX2019.mail.lan]

+ CategoryInfo : InvalidOperation : (DB01:ADObjectId) [Mount-Database], InvalidOperationException

+ FullyQualifiedErrorId : [Server=EX2019,RequestId=c51a831c-33e3-4a75-867f-51433b925ee2,TimeStamp=1/1/2020

4:13:12 AM] [FailureCategory=Cmdlet-InvalidOperationException] 7E29F70A,Microsoft.Exchange.Management.SystemConfigurationTasks.MountDatabase

+ PSComputerName : EX2019.mail.lan

L’erreur ci-dessus peut se produire pour diverses raisons. En voici quelques-unes

• Une mauvaise mise à jour
• Erreur humaine
• Défaillance du matériel
• Perte de puissance
• Attaques de logiciels malveillants et de logiciels rançonneurs
• Corruption ou problèmes de mémoire
• Défaillance de l’unité de stockage du serveur

Corrigez l’erreur “Le groupe de disponibilité de la base de données doit avoir un quorum”

Tout d’abord, vous devez vérifier si vous disposez de la majorité des votes dans votre cluster. Cela signifie que la moitié de vos serveurs plus un serveur sont en ligne et que tous les serveurs participants sont sains et opérationnels. Vous devez également vérifier que le stockage de chaque nœud et les services Exchange et cluster fonctionnent et qu’aucune erreur ne s’est produite. Si un problème matériel s’est produit et a mis le serveur hors tension, cela peut être un problème car le DAG ne peut pas fonctionner avec un seul des trois serveurs. Comme pour d’autres clusters (par exemple SQL), le cluster est arrêté par mesure de sécurité si la majorité des votes n’est pas atteinte.

Si tous les correctifs ont été apportés et qu’il n’y a rien à faire pour remettre les services en état, la seule option consiste à supprimer les copies de la base de données afin que le serveur soit en mode base de données unique.

Pour ce faire, exécutez la commande Remove-DatabaseAvailabiltyGroupServer dans le Shell de gestion Exchange. Cette commande supprime toutes les entrées DAG de l’Active Directory.

Remarque : il n’est pas nécessaire de créer au préalable une copie de sauvegarde de toutes les données, car seule la configuration est supprimée.

Remove-DatabaseAvailabilityGroupServer -ConfigurationOnly -MailboxServer SRV-MBX-01 -Identity DAG001

Ce processus doit être exécuté sur chaque nœud. Si votre groupe de disponibilité de la base de données (DAG) se compose donc de deux serveurs, vous devez effectuer les étapes ci-dessus sur les deux serveurs.

Dès que ce processus est terminé, la configuration du Database Availability Group (DAG) est supprimée de l’Active Directory.

L’étape suivante consiste à supprimer les nœuds du cluster Windows. Cependant, vous ne pouvez pas utiliser le gestionnaire de cluster pour ce processus. Vous devez utiliser PowerShell. Le processus est assez simple car il vous suffit d’utiliser Get-ClusterNode et Remove-ClusterNode avec le paramètre force (comme dans l’exemple ci-dessous).

Get-ClusterNode <nom du serveur> | Remove-ClusterNode -Force

Si la configuration d’Exchange Server pour le groupe de disponibilité de la base de données (DAG) consiste en deux serveurs ou plus, vous devez effectuer cette opération pour chaque nœud de votre cluster.

Toute configuration du groupe de disponibilité de la base de données est alors supprimée du schéma Active Directory et l’installation doit être convertie en serveur autonome. Cela signifie qu’après le redémarrage du serveur, la base de données doit être montée car elle a été retirée du groupe de disponibilité de la base de données (DAG).

Que dois-je faire si les bases de données ne sont toujours pas montées ?

Si nous disons maintenant que les bases de données devraient être montées sans problème, cela signifie que les bases de données n’ont pas été corrompues. Si les bases de données ne sont toujours pas montées, vous devez les vérifier à l’aide des outils natifs fournis avec Exchange Server, tels que ESEUtil.

ESEUtil est un outil natif qui identifie les problèmes et tente de réparer les bases de données endommagées. Il doit être exécuté via une interface de ligne de commande.

Pour déterminer si la base de données est corrompue, vous devez exécuter ESEUtil avec le paramètre /mh et vérifier l’état de la base de données. Une base de données saine aura l’état Clean Shutdown, tandis qu’une base de données endommagée affichera Arrêt brutal.

EseUtil /mh <fichier de base de données Exchange>

ESEUtil propose deux options pour la récupération des données : la récupération douce et la récupération dure. La récupération douce, comme son nom l’indique, effectue une récupération douce/rapide de la base de données. Si les dommages sont mineurs, la récupération douce des données tente de résoudre le problème.

Si cette opération échoue et que la base de données reste dans l’état “Arrêt brutal“, cela signifie que les dommages sont graves. Dans ce cas, la seule solution consiste à remettre les bases de données en état à partir d’une sauvegarde. Toutefois, cela entraînera une perte de données, car vous ne pouvez remettre en état que les données de la dernière sauvegarde. L’autre option consiste à effectuer une récupération des données sur le disque dur. Cela entraîne également une perte de données, car la récupération sur le disque dur supprime toutes les données considérées comme endommagées. D’autre part, Microsoft ne vous soutiendra pas si la base de données est classée dans la catégorie des récupérations dures. En outre, il n’y a aucune garantie que la base de données puisse être montée par la suite.

Comme alternative saine, vous pouvez utiliser une application tierce comme Stellar Repair for Exchange, qui est facile à ouvrir n’importe quelle base de données Exchange Server dans n’importe quel état et vous permet de lire et de rechercher le fichier EDB. Vous pouvez exporter les données vers PST et d’autres formats. Le logiciel de récupération de données Exchange Server dispose également d’une fonctionnalité permettant d’exporter directement vers une base de données Exchange Server en direct ou un locataire Office 365.

Was this article helpful?

YES0

NO

A propos de l'auteur

Himanshu Shakya

Himanshu is a Tech Enthusiast and Blogger at Stellar, with expertise in data recovery solutions and a keen interest in emerging technologies. Fluent in Japanese, he brings a diverse skill set to his role, contributing to global tech conversations. Outside of work, Himanshu enjoys playing chess, sharpening his strategic thinking and problem-solving skills in his spare time.