Reconstruction de l’index de recherche

Ajouter un champ à actAs: Searchable ne réécrit rien. Cette page dit pourquoi, et comment reconstruire post_index pour le catalogue déjà publié.

Pourquoi c’est un geste séparé

post_index n’est alimenté qu'à l’écriture d’un Post. Déclarer un champ indexable change ce qui sera écrit la prochaine fois ; cela ne touche pas les 8 100 morceaux déjà publiés.

Sans reconstruction, la recherche trouve le nouveau champ uniquement sur les morceaux postés après la livraison. C’est un demi-état pire que l’état précédent : les résultats dépendent alors de la date de publication d’un morceau, et rien sur le site ne le dit.

L’ordre des gestes, qui est une contrainte

Le code part d’abord, la reconstruction suit.

C’est l’inverse de l’ordre de la migration utf8mb4, et pour une raison opposée : là-bas l’encodage de connexion devait attendre la conversion des tables ; ici un index reconstruit avant que le champ soit déclaré indexable ne contiendrait pas ce champ, et le travail serait à refaire.

Le déploiement n’exécute aucune migration — Plesk tire main, un point c’est tout. La reconstruction se lance donc à la main, par le détenteur des accès.

Mesurer avant

body est un mediumtext ; les titres et les artistes sont des chaînes courtes. Indexer les messages peut produire un nombre de lignes sans commune mesure avec l’existant.

php symfony musiqueapproximative:reconstruire-index-recherche --mesurer-seulement --env=prod

Elle rend le nombre de lignes et les octets occupés, sans rien modifier. Noter les deux chiffres avant de lancer la reconstruction : ils sont ce qui permettra de dire si le coût est raisonnable.

Table 1. Mesure faite sur la copie de développement le 2026-08-30, catalogue de 8 216 morceaux
	lignes	taille
avant — artiste et titre seulement	37 744	6,0 Mo
après — avec le message	144 467	20,9 Mo
rapport	×3,8	×3,5

Le verdict est bon : vingt et un mégaoctets d’index pour dix-huit ans de catalogue. La mesure qui pouvait faire renoncer à ce travail ne le fait pas.

Table 2. Reconstruction menée en PRODUCTION le 2026-08-30, catalogue de 8 228 morceaux
	lignes	taille
avant	37 804	7,0 Mo
après	144 627	24,1 Mo

La production a confirmé la copie de dev à moins de 0,2 % près sur le nombre de lignes. Durée : quelques minutes, par lots de 200, sans interruption de service — post_index est une table dérivée, aucune donnée de morceau n’est touchée.

Vérifié après coup : une recherche sur krautrock remonte deux morceaux publiés en 2016 et en 2022, dont ni le titre ni l’artiste ne contiennent le terme. C’est la preuve que la reconstruction a porté sur le catalogue existant, et pas seulement sur les morceaux récents — la seule chose que cette page avait besoin d’établir.

Lancer

Relever la limite mémoire. La tâche meurt à environ 1 000 morceaux avec les 128 Mo par défaut du CLI. Ce n’est pas une fuite du code du projet : il n’hydrate aucun objet — il lit en HYDRATE_ARRAY et ne garde rien. La consommation vient de la couche connexion de Doctrine 1, qui accumule sur les centaines de milliers d’instructions qu’une réindexation complète émet.

Mesuré : 1 Go suffit largement pour les 8 216 morceaux.

php -d memory_limit=1G symfony musiqueapproximative:reconstruire-index-recherche --env=prod

La tâche traite les morceaux par lots de 200, avance par identifiant croissant — et non par offset, dont le coût monte avec l’avancement — et rend compte du dernier identifiant traité à chaque lot.

Elle est rejouable et interruptible : elle n’a pas d’état propre, chaque morceau réindexé écrase ses propres lignes. L’arrêter au milieu laisse une partie du catalogue réindexée et le reste tel quel ; la relancer termine le travail. Deux exécutions complètes donnent le même index.

Un morceau posté pendant la reconstruction peut être manqué selon le moment. Relancer la tâche après coup ne coûte que du temps.

Si elle s’interrompt, le journal donne le dernier identifiant traité. La relancer reprend depuis le début mais ne réécrit que ce qui l’a déjà été : le travail restant est le même, seul le temps est perdu.

Après

Comparer la taille à celle relevée avant.
Sur le site, chercher un mot présent seulement dans le message d’un morceau ancien. Le morceau doit remonter. C’est la seule vérification qui prouve que la reconstruction a porté sur le catalogue existant et pas seulement sur les morceaux récents.
Vérifier qu’un nom de contributeur ne remonte rien par lui-même — il n’est pas indexé, délibérément.

Retour en arrière

Retirer le champ de actAs: Searchable, régénérer les modèles, relancer la reconstruction. L’index redevient ce qu’il était.

Aucune donnée de morceau n’est touchée à aucun moment : post_index est dérivé, il se reconstruit intégralement depuis les Post.