Solr Alfresco : diagnostic, réindexation et retour à la normale

Une recherche Alfresco incomplète ne justifie pas immédiatement une réindexation totale. Il faut d’abord distinguer retard d’indexation, erreur de transaction, problème de contenu et saturation de Solr afin de choisir la correction la moins risquée.

Ce sujet merite un article a part entière parce qu’il ne se confond ni avec une montee de version Alfresco Community, ni avec une simple installation. Une indexation defaillante peut survenir après un incident, une reprise incomplete, un changement d’infrastructure, une saturation disque, un mauvais arrêt de service ou une intervention trop brutale sur les répertoires d’index. Sur le terrain, nous recommandons d’aborder le diagnostic Solr avec une logique simple : vérifier avant de réindexer, cibler avant de purger, et confirmer le retour à la normale avant de clore l’incident.

Quels symptômes doivent faire suspecter Solr dans Alfresco

Le premier signal est presque toujours métier : un document nouvellement verse n’apparait pas dans les résultats, une recherche plein texte ne retrouve plus un fichier connu, ou un dossier semble vide dans un résultat filtre alors qu’il contient bien des pieces. Dans d’autres cas, c’est l’équipe technique qui observe un decalage entre la base et l’index, des transactions en erreur, ou un temps de rattrapage anormalement long.

Les symptômes typiques sont les suivants :

• recherche incomplete sur des documents pourtant consultables par URL directe ;
• délai d’apparition anormalement long après import ou modification ;
• facettes ou filtres incohérents ;
• ecart entre les permissions attendues et les résultats visibles ;
• jobs d’indexation qui accumulent du retard ou des erreurs.

Il faut aussi distinguer une vraie panne Solr d’un problème de parametrage fonctionnel. Une recherche mal formulee, un modèle de métadonnées change sans recette complète, ou un plan de classement repense sans reprise propre peuvent produire des effets proches. C’est pour cela qu’un bon diagnostic commence toujours par une vérification croisee avec les contenus, les dates de depose et les cas d’usage métier. Cette discipline est la même que pour une installation Alfresco Community avec Docker Compose : on valide d’abord les prérequis et l’état reel de la plateforme avant d’engager une action irreversible.

Commencer par vérifier la sante de la chaine de recherche

Avant de parler réindexation, il faut confirmer que la chaine complète fonctionne : accès applicatif, connectivite entre Alfresco et Solr, espace disque, logs, et état des cores de recherche. Une réindexation lancee alors que le service Solr est instable ou que le stockage est sature risque seulement de rallonger l’incident.

Dans un diagnostic de premier niveau, nous recommandons de vérifier au minimum :

• l’état des services Alfresco et Solr, et leur date de dernier redémarrage ;
• la disponibilité réseau et les ports attendus entre le dépôt et le moteur de recherche ;
• les logs d’erreur repetitifs côté Solr et côté repository ;
• la croissance des répertoires d’index et l’espace libre restant ;
• la présence d’un incident recent : restauration, snapshot, upgrade, import massif, changement SSL ou reverse proxy.

Ce cadrage évite un anti-pattern classique : supprimer les index trop vite. Tant que l’on n’a pas identifié si l’anomalie concerne quelques transactions, un type de document, un core precis ou tout le referentiel, une suppression globale des index reste une décision disproportionnee. Les documentations Alfresco officielles insistent d’ailleurs sur la différence entre fix, reindex cible et full reindex complet : ce ne sont pas les mêmes impacts, ni les mêmes temps de retour au service.

Choisir entre correction ciblee et réindexation complète

La bonne question n’est pas “comment réindexer Solr ?”, mais “quel est le plus petit perimetre de correction qui remettra la recherche en cohérence ?”. Dans de nombreux environnements, une réindexation complète n’est pas nécessaire. Elle consomme du temps, peut retarder l’exploitation et complique la lecture des symptômes si le problème initial n’etait pas lie à l’index lui-même.

Une correction ciblee est généralement suffisante lorsque :

• l’incident ne concerne qu’une transaction ou un lot limite ;
• les erreurs sont apparues après une opération métier identifiable ;
• les cores restent globalement sains ;
• la file d’indexation n’est pas massivement en retard.

à l’inverse, une réindexation complète devient plus credible quand les index ont ete corrompus, supprimes partiellement, reconstruits de facon heterogene ou rendus incohérents par un incident d’infrastructure plus large. Elle peut aussi être imposee lors de certains changements de version ou de topologie de recherche. Dans ce cas, il faut la traiter comme une opération encadree, pas comme un simple bouton de maintenance.

Une méthode pragmatique pour réindexer sans aggraver l’incident

Quand la décision de réindexer est prise, le plus important est de conserver une trace claire du point de départ, des hypotheses et du perimetre retenu. Sur des environnements de production, nous conseillons de documenter la date de debut d’incident, les symptômes observables, les contenus de test utilises pour la validation et la méthode de retour arrière si la remise en service echoue.

Une sequence de travail raisonnable ressemble a ceci :

1. confirmer que le problème vient bien de l’index et non des droits ou du parametrage métier ;
2. identifier si l’action peut rester ciblee sur des transactions, des nœuds ou un core ;
3. stabiliser l’infrastructure avant toute reconstruction ;
4. exécuter la correction ou la réindexation dans une fenêtre maitrisee ;
5. vérifier la reprise avec des cas de recherche reels et pas uniquement avec un statut technique.

Cette démarche rejoint ce que nous recommandons aussi sur les projets de migration Alfresco : un plan d’exécution n’a de valeur que s’il se termine par des tests métier lisibles. Il ne suffit pas qu’un service redemarre. Il faut prouver que les utilisateurs retrouvent les documents attendus, avec les bons droits et dans des délais normaux.

Les erreurs fréquentes pendant un incident Solr Alfresco

La première erreur consiste a relancer des services en boucle sans isoler le symptôme. Cela brouille la chronologie et peut transformer une desynchronisation partielle en indisponibilite plus large. La deuxieme est de supprimer les index sans sauvegarde ni estimation de duree, alors que l’environnement n’est pas pret a supporter le temps de reconstruction. La troisieme est d’oublier les tests métier : beaucoup d’équipes s’arretent des que l’interface d’administration semble rassurante.

Nous voyons aussi souvent ces points de fragilite :

• absence de supervision sur le retard d’indexation et les erreurs recurrentes ;
• aucune procédure d’incident formelle pour la recherche ;
• confusion entre panne Solr, panne base de données et problème de permissions ;
• environnement restaure sans vérification de l’état des indexes après reprise ;
• documentation d’exploitation trop faible pour savoir quoi tester après correction.

Si votre GED devient critique pour la qualité, la conformité ou la relation client, la recherche n’est pas un composant secondaire. Une indexation defaillante dégradé la confiance dans tout le système documentaire. C’est pourquoi la supervision, les tests de reprise et la documentation d’exploitation doivent faire partie du dispositif normal, au même titre que les sauvegardes ou les habilitations.

Comment confirmer le retour à la normale

La remise en service ne s’arrête pas au redémarrage de Solr ou à la fin d’une réindexation. Il faut valider des recherches representatives : un document recemment verse, un document ancien, une recherche plein texte, une recherche par métadonnée, un test sur des droits differencies, et un cas métier connu des utilisateurs. C’est cette combinaison qui permet de conclure que l’incident est réellement clos.

Nous recommandons aussi de garder une trace de trois éléments pour les incidents suivants : le symptôme initial, la commande ou l’action finalement utile, et les contrôles qui ont permis de confirmer la résolution. Cette base de retour d’expérience est precieuse pour accelerer les prochains diagnostics, surtout quand plusieurs administrateurs se relaient sur la plateforme.

Ce qu’il faut retenir pour une GED exploitable

Une recherche Alfresco instable ne se traite pas correctement avec une réindexation systématique. La bonne approche consiste a qualifier le symptôme, vérifier la chaine de recherche, choisir le plus petit perimetre de correction, puis confirmer le retour à la normale avec des tests métier. C’est cette rigueur qui permet de restaurer le service sans introduire un nouveau risque d’exploitation.

Votre problème de recherche nécessite-t-il vraiment une réindexation ? Demander un diagnostic Solr Alfresco.