Bases qui disparaissent

woueb · 29/12/2010 14:55:51

Bonjour,
je viens par ici en espérant que quelqu'un pourra m'aider...

Depuis une semaine, environ j'ai environ une trentaine de bases sur 50 qui disparaissent à chaque fois au courant de la nuit.
J'ai des bons backups, donc je peux restaurer le matin, mais ça commence à devenir "chiant".
Je vois pas ce qui pourrait faire ça.
Ce qui est plus étrange :
- les fichiers ont l'air toujours présents sur le disque (environ 11 Go de données) quand ça arrive,
- c'est toujours exactement les mêmes bases qui disparaissent.

L'environnement : Postgres 7.4.28, CentOS 5.4, pas de mises à jours automatique, pas de cron qui se déclenche à l'heure incriminée (environ 22h)
Chaque base à un "owner" qui est seul à pouvoir y accéder, et c'est cet owner qui est déclaré pour chacun des sites
Il n'y a pas de moyen d'accéder à Postgres depuis l'extérieur (pas de phpPgAdmin, pas de ports ouverts, etc.)

Voilà, en espérant que quelqu'un pourra m'aider !

daamien · 29/12/2010 18:49:02

Bonjour,

La première chose à dire c'est que la version 7.4 est périmée. Vous devez migrer vers une version plus récente le plus vite possible.

Avez-vous les extraits des journaux de log correspondants à la période ou les bases disparaissent ?

woueb · 29/12/2010 22:02:58

Bonjour,
malheureusement, je ne peux pas vraiment migrer dans l'immédiat, les bases hébergent une application non compatible avec la version 8 de Postgres (on a déjà essayé).

J'ai activé temporairement les logs, mais je n'ai rien trouvé (ni drop, ni revoke, ni update louche).

Quelqu'un m'a parlé de "vacuum" : il est vrai que j'ai un peu récupéré une patate chaude, et je n'ai jamais fait de plan de maintenance sur ce serveur.
Est-ce que ce serait une possibilité ?
Est-ce que je peux faire un "vacuumdb" sans crainte de perte de données ?

Merci !

gleu · 30/12/2010 00:41:40

Un VACUUM ne vous fera jamais perdre de données.

La seule possibilité de que je vois est que vous êtes touchés par un XID wraparound. À votre place, je ferais un VACUUM sur toutes les bases. Avec vacuumdb par exemple. Attention, n'utilisez pas l'option FULL.

De plus, j'activerais les traces des requêtes entre 21h et 23h par exemple. Il s'agit du paramètre log_statement. Vous auriez eu une version plus à jour, il aurait été possible de ne tracer que les requêtes de modification de schéma. Là, avec une 7.4, vous êtes obligé de tout tracer.

Si cela survient toujours, il serait intéressant de nous fournir le log qu'on regarde si on y voit quelque chose d'anormal.

woueb · 30/12/2010 01:38:26

Bon alors, le problème est réapparu ce soir, donc j'ai fait un "vaccum -a", et ça a reglé le problème.
Par contre, je comprends pas très bien, j'ai du faire 2 passages pour que le problème soit reglé.

Qu'importe le nombre de fois d'affilé que je le fais, j'ai toujours des index qui sont supprimés, etc., c'est normal je suppose ?

Est-il possible de savoir (rapidement ou avec de la doc) ce qu'est un "XID wraparound" ?

En tout cas, merci pour l'aide !

gleu · 30/12/2010 09:47:51

Non, ce n'est pas normal, rien ne doit être supprimé sans que vous le demandiez. Avez-vous activé les traces de log_statement ?

Pour le XID wraparound, chapitre 23.1.4, http://docs.postgresql.fr/9.0/maintenance.html

woueb · 30/12/2010 11:29:37

Merci pour le lien vers la doc.

Pour la suppression, je m'étais mal exprimé : c'est simplement qu'en faisant plusieurs vacuumdb en mode verbose (l'un après l'autre), je vois qu'il fait toujours des choses, même si le précédent vacuum date de quelques minutes avant.

Il me reste plus qu'à planifier des vacuum régulier via cron : je n'ai pas vu d'exemples dans la doc ?

gleu · 31/12/2010 00:39:55

C'est pourtant indiqué dans la documentation. Vous devez faire des vacuums réguliers. Vu votre version préhistorique, il faudra passer par cron ou les tâches planifiées suivant que vous êtes sous Linux ou sous Windows.

J'oubliais. Utilisez vacuumdb, c'est plus simple que de faire un vacuum via psql. Pour la doc sur cet outil, voir http://docs.postgresql.fr/7.4/app-vacuumdb.html .

woueb · 31/12/2010 09:55:48

Merci pour tout, bonne année !

woueb · 03/01/2011 11:05:32

Bonjour,
je ne sais pas si c'est relatif au vaccumdb, mais c'est apparu depuis que je le fais : les schémas (j'ai un simple schema "public" pour chaque base) se sont dédoublés pour chaque base...

Qu'est-ce que je devrais faire ?
Je ne sais pas si je risque de perdre des données ou quelque chose , ni comment le régler ?

Marc Cousin · 03/01/2011 11:08:44

vacuum ne touche à rien, ni au niveau du schéma, ni au niveau des données. Il ne fait que détruire physiquement les vieilles versions d'enregistrements qui ne sont plus visibles par personne. Ça vient forcément d'autre chose.

Qu'appelez vous dédoubler, pour commencer ?

woueb · 03/01/2011 11:12:28

En fait, nos bases sont relativement simple de conception, il y avait un schéma "public" par base.
Or je viens de remarquer que maintenant j'ai 2 schémas "public" par base.

Marc Cousin · 03/01/2011 11:24:28

Vous n'avez qu'un seul schema (public). Par contre, vous avez deux fois une vue «beneficiaires» à l'intérieur, ce qui n'est pas normal.

Marc Cousin · 03/01/2011 11:27:13

D'ailleurs, c'est censé être impossible (étant donné qu'il y a une contrainte d'unicité sur relname, relnamespace sur pg_class).

Que retourne :
SELECT pg_class.oid,relname, relnamespace, nspname from pg_class join pg_namespace on (pg_class.relnamespace=pg_namespace.oid) where relname = 'beneficiaires';

woueb · 03/01/2011 11:29:31

Voici le résultat :

Marc Cousin · 03/01/2011 11:32:14

Pouvez vous vérifier que vous avez bien l'index UNIQUE «pg_class_relname_nsp_index» déclaré sur pg_class ?

Au passage, c'est quelle version de PostgreSQL ?

Dernière modification par Marc Cousin (03/01/2011 11:32:54)

woueb · 03/01/2011 11:32:51

Comment je fais pour vérifie ceci ?

Marc Cousin · 03/01/2011 11:33:37

Sous psql : «\d pg_classe»
Sous pgadmin3, allez regarder la définition de la table …

Marc Cousin · 03/01/2011 11:35:42

\d pg_class évidemment, pas pg_classe

woueb · 03/01/2011 11:40:32

C'est une version 7.4.28

Par ailleurs, voici ce que je vois avec phpPgAdmin, je vois 2 schemas public, et 2 vues identiques : http://img513.imageshack.us/i/03012011103427.png/

Marc Cousin · 03/01/2011 11:50:21

Cela veut dire que dans la table pg_class, vous avez deux enregistrements avec le même oid… et avec le même couple (relname, relnamespace).

C'est normalement impossible.

Vous avez une corruption grave de votre catalogue. Comme vous êtes en 7.4, qui n'est plus supportée depuis un moment, vous n'aurez pas d'aide des développeurs. À mon avis, vous avez eu un arrêt brutal de votre serveur, et vous avez un problème de paramétrage des écritures sur le disque (vous n'avez pas fsync à 'off' au moins ?).

Ce que je vous recommande, c'est déjà d'installer une version plus récente (supportée), de migrer vos bases dessus. Vous aurez certainement à faire beaucoup de travail manuel, vu le niveau de corruption…

Ou de faire appel à une société spécialisée dans PostgreSQL pour vous y aider.

woueb · 03/01/2011 11:54:26

Grumpf...
Non, pas d'arrêt brutal du serveur, et pas de fsync.

Du coup, je sais pas trop ce que je vais faire, je suppose qu'on va tenter de migrer...

Marc Cousin · 03/01/2011 11:57:10

C'est ce qui me semble le plus sage. Mais ce genre de corruption est vraiment très très rare. Et habituellement laisse présager soit un problème de paramétrage (le fsync à off), soit un problème hardware (ça pourrait être un disque ide ou sata, avec un cache en écriture activé, ou un contrôleur disque qui a un pb, ou un pb de mémoire, etc…).

woueb · 03/01/2011 12:02:36

C'est quasiment impossible que ce soit le hardware, car c'est une machine virtuelle.
Pour le reste, pas de fsync à off.

Marc Cousin · 03/01/2011 12:09:04

"C'est quasiment impossible que ce soit le hardware, car c'est une machine virtuelle."

La machine virtuelle, elle tourne sur quoi ?

#1 29/12/2010 14:55:51

Bases qui disparaissent

#2 29/12/2010 18:49:02

Re : Bases qui disparaissent

#3 29/12/2010 22:02:58

Re : Bases qui disparaissent

#4 30/12/2010 00:41:40

Re : Bases qui disparaissent

#5 30/12/2010 01:38:26

Re : Bases qui disparaissent

#6 30/12/2010 09:47:51

Re : Bases qui disparaissent

#7 30/12/2010 11:29:37

Re : Bases qui disparaissent

#8 31/12/2010 00:39:55

Re : Bases qui disparaissent

#9 31/12/2010 09:55:48

Re : Bases qui disparaissent

#10 03/01/2011 11:05:32

Re : Bases qui disparaissent

#11 03/01/2011 11:08:44

Re : Bases qui disparaissent

#12 03/01/2011 11:12:28

Re : Bases qui disparaissent

#13 03/01/2011 11:24:28

Re : Bases qui disparaissent

#14 03/01/2011 11:27:13

Re : Bases qui disparaissent

#15 03/01/2011 11:29:31

Re : Bases qui disparaissent

#16 03/01/2011 11:32:14

Re : Bases qui disparaissent

#17 03/01/2011 11:32:51

Re : Bases qui disparaissent

#18 03/01/2011 11:33:37

Re : Bases qui disparaissent

#19 03/01/2011 11:35:42

Re : Bases qui disparaissent

#20 03/01/2011 11:40:32

Re : Bases qui disparaissent

#21 03/01/2011 11:50:21

Re : Bases qui disparaissent

#22 03/01/2011 11:54:26

Re : Bases qui disparaissent

#23 03/01/2011 11:57:10

Re : Bases qui disparaissent

#24 03/01/2011 12:02:36

Re : Bases qui disparaissent

#25 03/01/2011 12:09:04

Re : Bases qui disparaissent

Pied de page des forums

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux