Maintenance, VACUUM et observation

Comprendre le mécanisme

MVCC laisse des versions de lignes devenues inutiles après les changements. VACUUM et autovacuum participent à leur gestion et à la prévention du wraparound des identifiants de transaction. ANALYZE met à jour les statistiques utilisées par le planificateur. Une transaction ouverte trop longtemps peut retenir des versions et gêner le nettoyage. Les symptômes doivent être corrélés à l’activité réelle et à la politique de maintenance.

Raisonner et vérifier

Surveillez requêtes lentes, attentes de verrous, durée des transactions, connexions et croissance des objets. Un pool limite et réutilise des connexions, sans rendre les requêtes plus correctes. Définissez des délais adaptés et une procédure d’annulation contrôlée. Une amélioration doit être mesurée avant/après avec des métriques comparables ; évitez une opération lourde choisie uniquement pour faire disparaître un compteur.

Statistiques et choix de plan

Le planificateur estime les lignes utiles à partir d’informations sur les données. ANALYZE met à jour des statistiques qui participent à ces estimations. Une modification importante de distribution peut rendre un diagnostic ancien moins représentatif. Comparez estimations et observations avant de conclure à un problème d’index. Un temps isolé ne dit pas si la cause est une cardinalité mal évaluée ou une attente extérieure au parcours choisi.

Le rôle de VACUUM

Le modèle de versions du moteur peut laisser des tuples devenus inutiles qui demandent une gestion de maintenance. VACUUM participe à ce cycle selon son contrat ; il ne constitue pas une sauvegarde et ne démontre pas une restauration. Gardez ces responsabilités séparées dans les procédures d’exploitation. Une opération de maintenance réussie ne remplace pas un exercice de reprise ni une vérification des données métier.

Transactions longues et rétention de versions

Une transaction ancienne conservant un snapshot peut gêner la récupération de versions et retenir des ressources. L’absence de requête active au moment d’une observation ne signifie pas forcément absence de coût. Relevez durée, état et propriétaire du parcours, puis définissez la bonne action selon le produit. Les tests de reprise doivent aussi vérifier que les connexions reviennent dans un état propre.

Localiser les attentes de verrou

Une latence SQL peut venir d’un verrou détenu ailleurs, pas seulement d’un plan lent. Identifiez la transaction qui attend et celle qui bloque, puis reliez-les aux opérations applicatives. Modifier un index sans cette observation peut laisser la cause intacte. Les preuves doivent préciser la chronologie et les ressources concernées, avec une reproduction de laboratoire lorsque c’est possible.

Observer sans créer une fuite

Les paramètres SQL et traces d’authentification peuvent contenir des informations personnelles ou des secrets. Définissez ce qui doit être collecté pour le diagnostic, les accès et la conservation. Une corrélation et une catégorie d’opération peuvent aider sans recopier toute valeur. Vérifiez les chemins d’erreur et les outils de support : ils ne doivent pas devenir un stockage sensible plus largement accessible que la base.

Relier l’alerte à une action

Une métrique seule n’assure aucune intervention. Une alerte utile possède un seuil justifié, une fenêtre, un responsable et une procédure de vérification. Le traitement doit distinguer symptôme et cause : une file de requêtes peut refléter une dépendance ralentie. Testez le déclenchement puis la disparition de l’alerte dans un environnement maîtrisé, en notant les faux positifs acceptés et les limites de détection.

Mesurer dans des conditions comparables

Les volumes, distributions, caches et charges concurrentes influencent les résultats. Pour comparer deux versions, conservez un scénario qui explique ce qui change et ce qui reste comparable. Une seule observation favorable ne démontre pas toute tendance. La conclusion doit annoncer son périmètre et sa variabilité utile, plutôt qu’un pourcentage de gain extrapolé à toutes les requêtes du service.

Le disque appartient au budget du système

Données, index et journaux consomment un stockage fini. La croissance et les marges de reprise doivent être surveillées avant la saturation. Un service peut continuer de répondre sur un petit contrôle alors qu’une opération utile ne peut plus écrire. Définissez les ressources couvertes par le contrôle de santé et les actions prévues ; l’existence du processus ne prouve pas sa capacité future.

Planifier les opérations et les connexions

Les commandes de maintenance ont des coûts et des contraintes propres. Leur planification doit respecter le trafic et les garanties du service. Un pool peut aider à gérer les connexions, mais ne rend pas automatiquement correctes les transactions ou invariants métier. Revoir la capacité du pool n’est donc pas une correction d’une réservation concurrente ; mesurez les ressources tout en conservant les tests de cohérence applicative.

Compléter la surveillance par une reprise testée

Un tableau de bord vert n’établit pas qu’une sauvegarde sera restaurable après un incident. Les données et procédures de secours doivent être exercées dans un périmètre distinct, avec des vérifications fonctionnelles. Conservez la version, les étapes et les limites de cet essai. La surveillance décrit un état observé du service ; la reprise démontre une capacité différente qui demande ses propres preuves.

Atelier guidé : lire, expliquer et vérifier le code

BEGIN;
SELECT * FROM lab_orders WHERE id = 1;
-- Le client cesse son travail sans COMMIT ni ROLLBACK.

L’extrait ouvre explicitement une transaction, effectue une lecture, puis laisse le client sans COMMIT ni ROLLBACK. Le SELECT ne ferme pas ce cycle à lui seul. La session peut donc conserver un état transactionnel dont la durée devient une information utile au diagnostic, même sans travail applicatif courant.

Dans le laboratoire, observez une session de ce type puis terminez-la proprement selon la procédure choisie. Comparez les ressources et états avant et après. Reproduisez ensuite un retour de connexion au pool pour vérifier que le prochain utilisateur ne récupère pas un état oublié. Le but est de relier la métrique de transaction ancienne à une action contrôlée, et non d’arrêter arbitrairement toutes les connexions dès qu’une latence apparaît.