Vous n'êtes pas identifié(e).
Pages : 1
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!
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 :-)
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!
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 ?
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...
En effet, et j'en ai plein d'autre comme ca...
J'espère avoir le temps de modifier les requêtes a problème et de repasser un plan de test complet derrière, pas évident d'ici la fin de la semaine...
J'ai du boulot ;-)
Pour info, je suis en 8.3
Je suis effectivement en train de mettre en place le partitionnement, qui semble être la solution qui aurait du être spécifiée depuis le début, car complètement adaptée à mon cas.
Merci pour la piste, qui aurait du être explorée lors de la conception, plutôt qu'a une semaine du déploiement...
Je vais y jeter un œil, et voir si cela est possible a mettre en place rapidement.
L'ennui, donc, est que je voudrais éviter (au moins dans un premier temps) de trop modifier la structure de ma base, car l'application doit être fonctionnelle la semaine prochaine, et seul ce problème subsiste.
Y a-t-il une configuration de postgresql (notamment les paramètres de réglage du vacuum et ru reindex ?) adaptée à mon cas, sans pour autant retoucher la structure ?
Merci!
Bonjour,
J'ai un gros soucis de maintenance de une base de données très volumineuse : presque 2 tera-octets répartis sur une table de près de 3 milliards de lignes ...
Cette dernière est donc très volumineuse, notamment une table qui contient des données enregistrées toutes les secondes, sous forme de 'bytea'.
En gros, je dois enregistrer 1 an de données, avec une précision à la seconde, pour 80 entitées. Puis une fois presques pleine, la base doit effectuer un roulement, remplaçant les données les plus vieilles par les nouvelles.
Pour cela, chaque nuit, les lignes correspondant aux jours "en trop" sont supprimées (afin de pouvoir être remplacées).
Sauf que l'espace disque n'est pas rendu pour autant...
Comme un simple autovacuum n'a pas suffit, j'ai cherché à mettre en place une solution "manuelle".
Après quelques lectures sur internet, j'ai testé une solution qui marche sur un test avec seulement 1 jour de données (4 gigas sur 7 millions de lignes):
- vacuum + analyze
- reindex
Mais avec une base plus grosse (dès qu'on atteint quelques semaines de données), l'analyse ne se lance même pas (ou en tout cas le mode verbose n'affiche rien, et attendre une nuit complète n'y change rien...)
Dans l'idéal, il faudrait que cette maintenance puisse se faire sans stopper les "enregistrements" pour autant.
Au pire, la maintenance devrait pouvoir etre effectuée le plus rapidement possible durant la nuit, pour ne stopper les "enregistrements" qu'un minimum de temps.
J'ai essayer de retoucher le fichier de config (nontament en augmentant le 'max_fsm_pages'), mais rien n'y fait...
Quelqu'un a-t-il une idée de config, ou une piste a essayer ?
Pages : 1
