Signes indiquant qu’une base de données Immich nécessite une maintenance ou un remplacement

Une base de données Immich simplement lente peut nécessiter une maintenance PostgreSQL de routine ou une correction des ressources ; une base de données qui présente des échecs répétés d’intégrité ou de récupération peut nécessiter une restauration ou un remplacement à partir d’une sauvegarde vérifiée.

N’utilisez pas « reconstruire la base de données » comme solution générique aux problèmes de performances. Distinguez d’abord la croissance normale, la fragmentation, les statistiques obsolètes, la maintenance bloquée et la latence du stockage d’une corruption ou d’un état de cluster irrécupérable. Préservez un point de récupération avant toute intervention intrusive, mesurez une seule modification de maintenance à la fois et ne passez à une restauration propre que lorsque les éléments disponibles indiquent que la base actuelle ne peut pas être considérée comme fiable ou réparée en toute sécurité.

Distinguer la dégradation des performances d’un défaut d’intégrité

Commencez par identifier précisément le symptôme : recherches lentes, requêtes de chronologie lentes, taille importante de la base de données, forte activité du disque, erreurs PostgreSQL répétées, boucles de récupération après incident ou migration Immich impossible à terminer. Les symptômes de performance et ceux d’intégrité présentent des risques différents et ne doivent pas recevoir la même première mesure corrective.

Vérifiez que l’hôte dispose toujours d’un stockage sain, de suffisamment d’espace libre, d’un comportement mémoire normal et qu’aucune tâche d’arrière-plan Immich ne s’emballe avant d’incriminer PostgreSQL. Un disque saturé ou défaillant peut donner l’impression qu’une base saine est lente et peut également provoquer de véritables dommages à la base si le stockage sous-jacent devient peu fiable.

Conservez les journaux, la version de la base de données, les versions des extensions, l’historique récent des mises à niveau ainsi qu’une sauvegarde ou un instantané avant toute maintenance intrusive. Si l’unique copie de la base de données est peut-être corrompue, n’effectuez pas de nettoyage destructif simplement pour voir si l’erreur disparaît ; conservez les éléments nécessaires à une décision de restauration maîtrisée.

Rechercher des signaux de maintenance mesurables

La maintenance de routine devient une piste plausible lorsque la base démarre et reste utilisable en interne, mais que les performances des requêtes ou l’espace disque occupé se dégradent avec le temps. Les éléments utiles comprennent l’accumulation de lignes mortes, des tables ou des index qui grossissent de manière disproportionnée, un autovacuum qui ne parvient pas à suivre le rythme, des statistiques obsolètes pour l’optimiseur ou une maintenance de longue durée bloquée par d’autres sessions.

Les tuples morts, la fragmentation, la pression liée au gel des tuples, les opérations VACUUM bloquées et une fréquence de vacuum insuffisante peuvent tous affecter la maintenance et les performances des requêtes PostgreSQL. Utilisez les signaux VACUUM au niveau des tables au fil du temps au lieu de supposer que la seule taille élevée d’un fichier de base prouve que la base doit être remplacée.

Si les statistiques indiquent une table ou un index précis, choisissez l’action de maintenance prise en charge la moins intrusive correspondant à cette observation et mesurez à nouveau. Évitez de passer directement à VACUUM FULL, à de vastes opérations REINDEX ou à un réglage arbitraire de l’autovacuum sur l’ensemble du cluster ; ces actions peuvent provoquer des verrous, des entrées-sorties ou une demande supplémentaire en espace disque, sans forcément résoudre le véritable goulot d’étranglement.

Vérifier que la fragmentation ou la croissance des index correspond au chemin lent

Comparez les objets impliqués dans les opérations Immich lentes avec la taille des tables et des index, le renouvellement des lignes et le comportement des requêtes. La fragmentation est importante lorsqu’elle augmente le travail nécessaire pour trouver les lignes utiles ou rend les index moins efficaces, mais la base peut également être volumineuse simplement parce que la photothèque et ses métadonnées sont importantes.

La fragmentation des tables et celle des index doivent être évaluées séparément, car une fragmentation excessive peut accroître le travail requis par les requêtes sans indiquer une corruption de la base de données. Utilisez des contrôles mesurés de la fragmentation PostgreSQL pour cibler un objet observé et actualisez les statistiques de l’optimiseur lorsque cela est pertinent, plutôt que de considérer la taille totale de la base comme un diagnostic.

Après la maintenance, relancez exactement l’action Immich qui était lente et comparez à la fois la latence visible par l’utilisateur et le comportement de la base et du stockage. Si l’opération ne s’améliore pas, rétablissez si possible les réglages précédents et recherchez plutôt les causes liées au stockage, aux schémas de requêtes, aux tâches d’arrière-plan ou à l’application, au lieu d’empiler d’autres modifications de la base de données.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Passer à la restauration ou au remplacement lorsque l’intégrité est incertaine

Le remplacement se justifie par des éléments indiquant que l’état actuel de PostgreSQL ne peut pas être considéré comme fiable ou récupéré en toute sécurité, et non par son ancienneté. Les exemples comprennent une corruption répétée de pages ou de sommes de contrôle, des échecs persistants au démarrage ou lors de la récupération malgré un stockage sain, un cluster endommagé après un incident de stockage incomplet ou un état de migration impossible à réparer par la procédure prise en charge.

Avant de déclarer la base perdue, démontrez qu’une sauvegarde connue comme fiable peut être restaurée dans un environnement PostgreSQL propre et compatible et qu’Immich peut la lire. Si la restauration propre fonctionne tandis que le cluster actuel reproduit le même échec d’intégrité, vous disposez d’arguments bien plus solides pour remplacer l’état de la base plutôt que de poursuivre une réparation sur place.

Réparez les problèmes localisés et réversibles tout en préservant l’état persistant incertain ; ne reconstruisez que lorsque la source de récupération est vérifiée et que la cible est reproductible. Appliquez également cette limite entre réparation et reconstruction d’Immich à la base de données. « Remplacement » doit signifier restaurer un état PostgreSQL compatible à partir d’une source connue comme fiable, et non changer de base parce qu’une requête est devenue lente.

Valider la base de données par des opérations de lecture, d’écriture et de sauvegarde

Que vous ayez effectué une maintenance ou restauré une base propre, validez le résultat via Immich plutôt que de vous arrêter à un démarrage réussi de PostgreSQL. Ouvrez d’anciens albums et éléments, effectuez des recherches, chargez des vidéos représentatives et vérifiez que les utilisateurs et les paramètres de partage apparaissent comme prévu.

Effectuez une nouvelle écriture sans risque, par exemple en téléversant un élément destiné à être supprimé, et vérifiez qu’il reste accessible après un redémarrage normal du service. Surveillez les journaux PostgreSQL et Immich à la recherche d’erreurs récurrentes d’intégrité, de migration, d’extension ou d’autorisation pendant que les chemins de lecture et d’écriture sont actifs.

Enfin, créez une nouvelle sauvegarde de la base avec votre méthode habituelle et testez sa restauration sur une cible isolée lorsque cela est possible. La décision de maintenance ou de remplacement n’est achevée que lorsque le système actuel est utilisable et que le prochain point de récupération est manifestement plus sain que l’état à l’origine de l’incident.