PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 17/12/2009 17:32:19

hfilliere
Membre

Comportement base de données PostgreSQL en cas de FS plein

Bonjour,

Que se passe t' il lorsque le FS hébergeant les bases de données PostgreSQL est plein.
Est-ce qu'il y a un crash éventuel? Quel est le comportement du moteur PostgreSQL?

merci de vos lumières.

Hfilliere

Hors ligne

#2 17/12/2009 18:20:34

gleu
Administrateur

Re : Comportement base de données PostgreSQL en cas de FS plein

Tant que PostgreSQL peut écrire dans ses journées de transactions, tout va bien. Dès que ce n'est plus le cas, il y a un message PANIC et le système s'arrête. Une fois que le ménage est fait, le DBA redémarre PostgreSQL qui va entrer dans un premier temps en mode restauration, puis accepter les connexions.


Guillaume.

Hors ligne

#3 18/12/2009 10:38:07

philwood
Membre

Re : Comportement base de données PostgreSQL en cas de FS plein

Bonjour,
Comment justement faire du ménage si le fs pgdata est plein si la base ne veut plus démarrer ? Personnellement, je supprime qq WAL sous pg_xlog pour pouvoir redémarrer mais peut-être y a t-il une autre solution ?
Cdt

Hors ligne

#4 18/12/2009 10:53:54

Marc Cousin
Membre

Re : Comportement base de données PostgreSQL en cas de FS plein

C'est vraiment le truc à ne pas supprimer, les WAL. On peut supprimer des vraies logs à la place par exemple.

Si on a la chance d'être sous Linux ou un autre système d'exploitation 'sérieux', il faut savoir que la plupart des FS ont un certain pourcentage de blocs réservés à l'utilisateur root (par exemple en ext2/3/4, on a 5% d'espace réservé). En cas d'urgence de ce genre, on peut faire baisser ce quota avec tune2fs -r.

C'est aussi à ce genre de moments qu'on est content d'avoir mis les LVM et gardé un peu d'espace non alloué…


Marc.

Hors ligne

#5 18/12/2009 11:31:19

gleu
Administrateur

Re : Comportement base de données PostgreSQL en cas de FS plein

En dehors des fichiers qui se trouvent dans le répertoire pg_log, il ne faut jamais rien supprimer. D'ailleurs, en toute logique, il ne faudrait pas non plus supprimer les fichiers de pg_log car ils peuvent aider à la compréhension du problème.

Ce qu'il faut faire, en pareille situation, c'est de déplacer certains objets sur un autre file system. Quelques tables par exemple. Les déplacer et faire un lien symbolique pour que PostgreSQL puisse les retrouver. Cela permettra de redémarrer PostgreSQL. Une fois ce dernier redémarré, il va être possible de créer un tablespace et de déplacer les objets de faire propre.

Mais en tout état de cause, il ne faut jamais supprimer des fichiers.


Guillaume.

Hors ligne

#6 18/12/2009 14:42:58

philwood
Membre

Re : Comportement base de données PostgreSQL en cas de FS plein

Mes logs étant sur un fs séparé, quand j'ai un pgdata full, il n'y a pas beaucoup de marges de manœuvre.
En fait, je parlais de WAL non archivés. Je rencontre souvent des pb sur le fs des archives full qui du coup remplit par vase communiquant le fs pgdata (pg_xlog).
Bonne idée l'option du lien symbolique.

Hors ligne

#7 18/12/2009 17:39:06

gleu
Administrateur

Re : Comportement base de données PostgreSQL en cas de FS plein

En fait, je parlais de WAL non archivés. Je rencontre souvent des pb sur le fs des archives full qui du coup remplit par vase communiquant le fs pgdata (pg_xlog).

Vase communiquant n'est pas vraiment la bonne image, mais passons.

C'est à cause de pb comme un FS full que sont sortis d'excellents produits comme Nagios.


Guillaume.

Hors ligne

#8 19/12/2009 09:30:03

jmax
Membre

Re : Comportement base de données PostgreSQL en cas de FS plein

gleu a écrit :

En fait, je parlais de WAL non archivés. Je rencontre souvent des pb sur le fs des archives full qui du coup remplit par vase communiquant le fs pgdata (pg_xlog).

Vase communiquant n'est pas vraiment la bonne image, mais passons.

C'est à cause de pb comme un FS full que sont sortis d'excellents produits comme Nagios.

la RFC 1157 qui définit le SNMP existe depuis 1990 car le besoin existe depuis très longtemps

Hors ligne

Pied de page des forums