Thursday, May 18, 2017

Exchange 2016 (20) : recréer un index en état d'échec

English summary : when verifying the status of our Exchange mailbox databases, we notice that the content indexes are in a failed state. We need to rebuild the content index which is a three part operation: stop Exchange services related to content indexing, delete the content index folder and then restart the Exchange services that were stopped. The indexes will be recreated. With a DAG, we can reseed the content index from a healthy copy. If all copies of the database have a failed index, we can rebuild one and then reseed from this good copy.

***

Scénario : nous vérifions l'état de nos bases de données de boîtes aux lettres et nous constatons que l'index du contenu ("Content Index") est corrompu.

Dans mon réseau d'essai, nous avons trois bases de données :

  • MBXDB-01\EX16-3 (Note : la base de données fait partie d'un DAG)
  • MBXDB-01\EX16-4 (Note : la base de données fait partie d'un DAG)
  • MBXDB-03\EX16-4 (Note : base de données à une seule copie - ne fait pas partie d'un DAG)

Pour une raison que j'ignore, l'index de chacune des trois bases de données est corrompu. Chose curieuse, les bases de données elles-mêmes semblent en parfait état. A mon avis, cet affichage montre ce qu'il faut savoir le mieux :



Alors, comment réparer nos index ?

Il s'agit d'un processus en trois étapes :

  • Nous arrêtons deux services touchant aux index : MSExchangeFastSearch et HostcontrollerService.
  • Nous supprimons l'index corrompu. Il s'agit en fait de supprimer un répertoire qui contient les fichiers composant l'index.
  • Nous faisons redémarrer les services que nous avons arrêtés. Exchange va constater l'absence de l'index et le recréer.

Si la base de données fait partie d'un DAG, il faut compter une autre étape. Dans les paragraphes qui suivent, je présente d'abord la marche à suivre pour une base à données à copie unique (qui ne fait pas partie d'un DAG) et ensuite pour une base de données à deux copies (qui fait partie d'un DAG).  

Remarque : faites surtout attention à supprimer l'index de la base de données et non pas la base de données elle-même !


Première étape

Nous arrêtons les services en question avec les commandes suivantes :

Stop-Service MSExchangeFastSearch
Stop-Service HostcontrollerService

Vous pourriez voir ceci :


C'est normal.

Nous pouvons vérifier l'état des deux services avec ces commandes :


Il est important que les services soient bel et bien arrêtés. Sinon, nous rencontrerions beaucoup de messages d'erreur en caractères rouges à la prochaine étape (supprimer les fichiers composant l'index).


Seconde étape

Voici le répertoire que nous devons supprimer :


Comme nous pouvons le voir, il correspond à la base de données MBXDB-03 qui se trouve seulement sur le serveur EX16-4. Il contient des sous-répertoires et des fichiers. Nous pouvons le supprimer dans l'interface graphique ou à la ligne de commande :

Remove-Item [GUID] -Recurse


Note : "gci" est un raccourci (ou "alias") pour Get-ChildItem. D'ailleurs, nous aurions pu utiliser "ri" comme raccourci pour Remove-Item. Le paramètre -Recurse est nécessaire si nous voulons tout supprimer d'un seul coup, au lieu de supprimer les sous-répertoires un à un au préalable (ce qui serait fastidieux).


Troisième étape

Après la suppression du répertoire contenant les fichiers de l'index, nous pouvons faire redémarrer les services suivants :

Start-Service MSExchangeFastSearch
Start-Service HostcontrollerService



L'état de l'index change. C'est maintenant "Crawling" (ou "rampant") :



Après une durée variable, l'index retrouve son état "sain" :



Chose bizarre, les deux autres index ont eux aussi retrouvé un état sain bien que rien n'ait été supprimé à cette fin. Je ne peux pas expliquer cette évolution inattendue. Je ne peux qu'émettre l'hypothèse que le redémarrage des services associés aux index ait provoqué une action réparatrice là aussi.

Attention : la reconstruction de l'index peut peser sur les ressources du système et prendre beaucoup de temps. Je crois avoir lu un exemple où elle a mis un jour. La taille des bases de données à indexer et la puissance du matériel sont deux facteurs à prendre en considération.

***

Mais que ferions-nous si nous avions un DAG (et si les index ne s'étaient pas réparés apparemment tous seuls) ?

Si tous les index étaient corrompus, nous réparerions l'un d'entre eux en suivant la méthode démontrée ci-dessus. Quand nous aurions un index en bonne santé, nous pourrions mettre à jour l'index encore corrompu avec la commande suivante : 

Update-MailboxDatabaseCopy MBXDB-01\EX16-4 -CatalogOnly

Nous désignons la base de données sur laquelle nous voulons agir. Exchange va chercher les données nécessaires à un serveur avec un index sain. Si nous n'avons que deux copies de la base de données, nul besoin de désigner l'autre serveur puisqu'il n'y a pas d'autre choix.

No comments:

Post a Comment