PostgreSQL
La base de données la plus sophistiquée au monde.

Ouverture de session

Navigation

Contactez-nous

Administration du site :
"equipe chez postgresqlfr point org"

Contact presse :
"fr chez postgresql point org"

Contact association :
"bureau chez postgresqlfr point org"

Questions PostgreSQL :
 IRC :
  serveur irc.freenode.net
  canal #postgresqlfr

Recherche

Accéder aux archives

« Octobre 2008  
Lun Mar Mer Jeu Ven Sam Dim
  1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31  

Syndication

Flux XML

Sondage

Quelle est la version de PostgreSQL la plus répandue sur vos serveurs ?
8.3
10%
8.2
42%
8.1
40%
8.0
2%
7.4
6%
7.3 ou antérieure
0%
Nombre de votes: 48
3 commentaires | anciens sondages
Accueil » forums » Technique - général

Répertoire PG_XLOG en contante augmentation

Technique - général | Répertoire PG_XLOG en contante augmentation

Par Arrown le 20/02/2008 - 20:12

Bonjour a vous,
J'ai cherché un réponse à mon problème mais sans aucune solution, si je n'ai pas de solution d'ici demain, mon serveur PG va sauté !!

SYSTEM : LINUX RED HAT 3.2.3-53
POSTGRES : 8.2.4

Voici les données du problème :
Hier mon serveur PG a figé, la raison du problème concernait la place disponible sur le serveur ! Je n'en avais plus.
J'ai un disque dur de 135 GO et une base PG de 8 Giga, j'ai cherché la raison, et cela venait donc du rep XLog qui contient plus de 7000 fichier de 16 MO et cela depuis l'installation du serveur (24/04/2007).
Je dois en avoir une 20aine de fichier par jour. (20 * 16 = 320MO)

Je ne sais pas la raison du problème, je n'ai pourtant dans mon programme, aucune utilisation de BEGIN TRANSACTION !

L'on ma dit que le moyen était de reprendre la backup et de réinstaller PG ! Mais je n'y crois pas franchement. Je ne trouve pas normal de refaire une installe PG par manque de place !

Est-ce que la méthode suivante vous parait correcte :
- Sauvegarde des 118 GO de fichier XLOG (l'on sait jamais)
- Arrêter le service PG
- Effectuer un PG_RESETXLOG
- Redémarré le service

?

Le truc c'est que j'ai réussi a libérer 700 MO mais d'ici demain soir, cette place sera utilisé de nouveau par de nouveau fichier XLOG !! Je vais à la cata !

Une idée ?

Merci a vous.

Sylvain.

[ sujet précédent | sujet suivant ]

Options d'affichage des commentaires

Sélectionnez la méthode d'affichage des commentaires que vous préférez, puis cliquez sur "Sauvegarder les paramètres" pour activer vos changements.

Bien, j'ai donc tenté ma sol

Arrown/ = 22 Février, 2008 - 10:36

Bien, j'ai donc tenté ma solution et elle as marché parfaitement.

Je conseil donc le pg_resetxlog pour résoudre les probleme de transaction interminable malgré un stop and start de PG.

Maintenant, je pense que le problème était survenu durant une transaction qui ne se terminait jamais et il gardait tout se qu'il se passait depuis se problème.

Depuis le reset, je n'ai plus que 3/4 fichiers seulement et pas plus.

Parfait. En espérant que quelqu'un se serve de ce post pour un probleme similaire dans le futur.

PS : Vérifier avant que le pg_resetxlog soit de la même version que votre PG (./pg_resetxlog --version)


[ Vous devez vous connecter pour poster des commentaires ]

Houla !!

Jean-Paul Argudo/ = 22 Février, 2008 - 11:47

Bonjour,

Dommage que je n'aie pas vu votre post avant :-( ...
En utilisant la commande pg_resetxlog, vous avez probablement perdu des données. L'utilisation de cette commande n'est réservée qu'à des cas très particuliers..

À mon avis votre soucis vient d'ailleurs, et risque de se reproduire. Ce n'est certainement pas liée à une transaction particulière d'ailleurs. Par contre votre post m'amène à vous poser des questions et à vous faire quelques remarques:

  • postez en fichier attaché votre fichier postgresql.conf, votre problème réel s'y trouve probablement...
  • vous devez surveiller l'espace disponible de votre serveur. Ce n'est pas une option, vous devez connaître l'état de l'espace disponible, et lever une alerte simple à 80%, et une alerte grave à 90% d'occupation de vos disques
  • vous auriez du identifier le processus qui crée les WALs, utiliser pg_resetxlog n'est pas une solution!
  • enfin, par pitié, même si j'apprécie votre auto-réponse à votre problème, ne conseillez pas pg_resetxlog à la légère comme étant une solution à ce problème, ça ne l'est pas.

Cordialement,

--
Jean-Paul ARGUDO
http://dalibo.com | http://dalibo.org


[ Vous devez vous connecter pour poster des commentaires ]

Conf

Arrown/ = 22 Février, 2008 - 15:09

Bonjour, je prend note pour l'utilisation de PG_ResetXLog mais je n'avais aucune autre solution pour y remédier. (la boite se figeait si je n'intervenais pas).

Pour l'espace, j'ai maintenant une alerte par mail (webmin) qui me dit lorsque le seuil de place disponible vient d'être dépassé.

Quand vous dites "vous auriez du identifier le processus qui crée les WALs", le problème c'est que je ne vois pas comment j'aurai pu faire, malheureusement.

Donc ma question revient sur le plateau : "Comment forcer l'écriture des WALs a un instant T ? (pour vider pg_xlog, sans pg_resetxlog)"

(Pour le fichier, je ne vois pas ou poster "postgres.conf" sur ce site ! je vais chercher)


[ Vous devez vous connecter pour poster des commentaires ]

Bonjour, Votre problème m

ThomasReiss/ = 26 Février, 2008 - 22:46

Bonjour,

Votre problème me fait fortement penser à un archivage défaillant des WALs. Avez-vous positionner le paramètre archive_command qui permet l'archivage des WALs s'il est non vide.


[ Vous devez vous connecter pour poster des commentaires ]

© PostgreSQLFr, tous droits réservés.
Site déclaré à la CNIL sous le numéro 1074678, conformément à la Loi en vigueur.