Vous n'êtes pas identifié(e).
Pages : 1
Bonjour ,
je suis un nouvel utilisateur Postgres , je me familiarise avec le produit.
J'ai créé une db dans laquelle on insert et delete pas mal de records . La taille des tables augmentent donc considérablement . Pour récupérer l'espace disk , je lance un Vacuum .
Deux questions :
1) la table est lockée pendant le vacuum , y-a-t-il une possibilité de lancer un vacuum sans locker la table .
2) les indexes sont aussi recréés . Est-il possible de ne pas générer les Wals pendant le vacuum et la création des indexes ?
Merci pour vos réponses
Hors ligne
1. Ne pas faire de VACUUM FULL mais s'assurer qu'il y a suffisamment de VACUUM simple (soit par l'autovacuum soit par un cron).
2. Non. Les WAL sont là pour éviter tout risque de corruption.
Pour le dire plus simplement, le VACUUM FULL est une fausse solution dans 90% des cas.
Guillaume.
Hors ligne
Merci pour l'info .
Je vais tester tout cela
Hors ligne
Bonjour,
j'ai killé un vaccuum full et je m'aperçois que l'espace déjà utilisé par le vacuum n'est pas récupéré . Comment identifier cet espace alloué temporairement par le vacuum . Je voudrais le remover de mon disk .
Merci pour vos bons conseils
Hors ligne
Hors ligne
J'ai killé le process vacuumdb . Je sais que ce n'est pas très 'propre' mais dans le même temps je simulais un crash .
Je ne l'aurais pas killé sur une db de production.
Hors ligne
Tuer vacuumdb n'est en aucun cas un problème, c'est juste un client. Par contre, il est possible que la commande SQL ait continué un moment sur le serveur vu que ce dernier n'a pas été averti de la mort du client. Donc à mon avis, c'est juste temporaire. En tout cas, je ne vous conseille pas de supprimer quoi que ce soit vous-même. Il y a bien plus de chances de faire une bêtise que de réparer quelque chose (qui, à mon sens, n'est pas cassé).
Guillaume.
Hors ligne
Merci pour vos réponses.
Effectivement la db n'est pas corrompue. Je l'ai arrêtée et redémarrée sans problème . Cependant je n'ai toujours pas récupéré mes 30 gigas .
Ce sont probablement des fichiers temporaires créé par Vacuum . Donc je réédite ma question : comment récupérer cet espace ?
Hors ligne
Je réitère également ma question : comment exactement avez vous tué ce processus ? kill -9 ? Etait-ce le processus client ou serveur ?
En partant du principe que c'était un kill -9 du processus serveur, effectivement je pense que les fichiers en cours d'utilisation ne seront pas supprimés automatiqement, car c'est ce que qui est implicitement demandé avec un kill -9 d'un processus serveur.
Si vous voulez récupérer les fichiers, le moyen le plus sur serait un dump/restore. Vous pouvez sinon jouer avec la liste des fichiers présents dans la base ayant une extension .29 (en supposant que les 30 giga viennent d'un seul objet) et la liste des fichiers qui devraient être présents (colonne relfilenode de la table pg_class) par exemple. Mais si vous ne savez pas trop ce que vous faîtes, vous avez plus de chance de supprimer un mauvais fichier et donc corrompre votre instance.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
effectivement j'ai killé par un kill -9 . Merci pour vos infos . Je regarde cela tranquillement .
Bon we
Hors ligne
Ok. Pour information, vous pouvez arrêter une requête en cours d'exécution avec la fonction pg_cancel_backend(pid), ou tuer la connexion proprement avec pg_terminate_backend(pid). Si vous souhaitez vraiment utiliser kill, alors le signal par défaut (SIGTERM) sera correctement géré par postgres.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
