Vous n'êtes pas identifié(e).
Bonjour,
J'ai un gros soucis, urgent qui plus est, car l'appli sur laquelle je travaille doit etre fonctionnelle jeudi au plus tard...
J'ai une grosse base de données (3 To), pour laquelle la maintenance est faite manuellement.
Je n'ai donc pas besoin d'autovacuum, et pour cela j'ai les 2 lignes suivantes commentées dans le fichier autovacuum.conf :
#track_counts = on
#autovacuum = on
Pourtant, au lancement de la base de données, j'ai le processus suivant qui se lance (et qui risque de prendre pls jours vu la taille de la BD...):
"postgres: autovacuum launcher process"
Cela m'empeche tout simplement d'insérer une nouvelle colonne dans ma base de données:
"database is not accepting commands to avoid wraparound data loss in database"
Pourriez-vous m'indiquer comment stopper l'autovacuum, ou mieux encore comment réellement l'empecher de s'executer ?
A défaut, y a-t-il un moyen d'ajouter ma colonne malgrés l'autovacuum ?
Merci de votre aide, je commence vraiment à désespérer...
Hors ligne
Apparemment l'autovacuum semble inevitable, pour mettre a jour les identifiants de transaction qui atteigne leur valeur limite.
Si cette opération est vraiment vitale, pourriez-vous au moins m'indiquer comment ajouter une nouvelle colonne malgrés tout, en parallèle ?
Hors ligne
Bonjour,
Je vous recommande tout d'abord une relecture très attentive du chapitre
" 23.1.4. Éviter les cycles des identifiants de transactions" sur la page:
http://docs.postgresqlfr.org/8.4/mainte … -vacuuming
Ce qui vous arrive, c'est que vous approchez de la limite fatidique où les identifiants de transaction vont être recyclés. Le VACUUM est donc inévitable et vous *devez* le faire.
Comme il est dit dans ces pages, vous devrez ARRETER votre serveur, puis passer en mode mono-utilisateur en lançant à la main un processus "postgres", comme il c'est indiqué sur cette page (cherchez le mot-clé "--single"):
http://docs.postgresqlfr.org/8.4/app-postgres.html
Maintenant, 2 remarques complémentaires:
* autovacuum = on commenté ne suffit pas pour le désactiver ! Il est en effet activé par défaut dans votre versions)
* vous dites faire une maintenance manuelle de la base (pas d'autovacuum): cette façon de procéder a manifestement ses limites à présent, puisque vous arrivez en recyclage des ID de transaction :-/ Il faudra dont veiller à augmenter la fréquence des VACUUM, ou alors, ce qui est plus sage, d'opter pour un autovacuum activé.
En tout cas, tant que le VACUUM ne sera pas fait en mode single user (arrêt des applications à faire donc!), vous ne pourrez plus rien faire sur cette base, par mesure de sécurité (cf le chapitre 23.1.4 que vous allez donc lire en entier!).
Bon courage pour la suite,
Jean-Paul Argudo
https://www.postgresql.fr
https://www.crunchydata.com
Hors ligne
Bonjour,
Merci pour votre réponse, qui confirme les conclusions auxquelles j'étais arrivé, en lisant justement les points que vous soulignez (mais en anglais, merci pour les liens français au passage!)
Je souhaite réellement désactiver l'autovacuum, car mes tables sont générées dynamiquement par héritage, ce qui me permet d'effacer les données avec des truncate. Faut-il explicitement indiquer "autovacuum = off" ? Cela risque-t-il de me créer des soucis dans mon cas (apparemment le vacuum lié aux indexes des transactions se fait de toute manière...) ?
Malheureusement, j'ai tellement de données qu'effectivement les identifiants de transactions arrivent à leur limite!
Je vais donc être obligé de lancer un autovacuum, et d'attendre qu'il ai fini, ce qui risque d'être (très) long, vu la quantité de données ( presque 500 tables de 2 GBs chacune...)
A moins qu'il ne soit possible d'ajouter une colonne dans une table, de manière indépendante du vacuum ? Cela m'arrangerait vraiment, car toute mon appli est bloquée alors que je n'ai besoin que d'un inoffensif "alter table add column"...
Encore merci de votre aide!
Hors ligne
Vous avez 2 possibilités : passer autovacuum à off (je ne le ferais pas à votre place, c'est quand même une sécurité), et modifier la définition des tables en question pour y désactiver l'autovacuum (regardez la doc de la clause WITH de CREATE TABLE et ALTER TABLE, vous pouvez y spécifier autovacuum_enabled à true ou false par table)
Marc.
Hors ligne
Désactiver ou pas l'autovacuum importe peu. Dans le cas présent, quelque soit la configuration, l'autovacuum bossera quand même (à partir de la 8.1).
Quant à la maintenance de cette base, elle est peut-être faite, mais dans ce cas elle est mal faite. Sinon on ne serait pas dans un cas de XID Wraparound.
Guillaume.
Hors ligne
Re-bonjour,
Suivant vos conseils (et la doc), j'ai stoppé la BD, et j'exécute un vacuum en mode single user.
Je lance le vacuum en mode verbose, table par table, au moins dans un premier temps pour avoir un ordre d'idée du temps total de l'opération (qui risque de prendre plusieurs jours dans mon cas, j'en ai bien peur)
Mon pb est que le mode verbose n'affiche aucun détail dans le mode single user... Avez-vous une idée la dessus ?
Encore merci pour votre aide :-)
Hors ligne
Problème finalement réglé, merci!
En effet, le pb des identifiants de transaction se posait en fait sur une seule table bien particulière, d'environ 10 GBs, et je n'ai donc pas eu besoin d'effectuer le vacuum sur mes 500 tables de plusieurs gigas chacune, ce qui aurait pris un temps fou.
Je remet l'autovacuum pour cette fameuse table qui a posé problème, et le tour sera joué!
Merci à tous!
Hors ligne
