Vous n'êtes pas identifié(e).
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 ! 
Hors ligne
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 ?
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
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 !
Hors ligne
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.
Guillaume.
Hors ligne
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 !
Hors ligne
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
Guillaume.
Hors ligne
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 ?
Hors ligne
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 .
Guillaume.
Hors ligne
Merci pour tout, bonne année !
Hors ligne
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 ?
Hors ligne
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 ?
Marc.
Hors ligne
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.
mabase=# \dv
List of relations
Schema | Name | Type | Owner
--------+---------------+------+----------
public | beneficiaires | view | monutilisateur
public | beneficiaires | view | monutilisateur
Hors ligne
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.
Hors ligne
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';
Marc.
Hors ligne
Voici le résultat :
mabase=# SELECT pg_class.oid,relname, relnamespace, nspname from pg_class join pg_namespace on (pg_class.relnamespace=pg_namespace.oid) where relname = 'beneficiaires';
oid | relname | relnamespace | nspname
----------+---------------+--------------+---------
82810483 | beneficiaires | 2200 | public
82810483 | beneficiaires | 2200 | public
Hors ligne
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)
Marc.
Hors ligne
Comment je fais pour vérifie ceci ?
Hors ligne
Sous psql : «\d pg_classe»
Sous pgadmin3, allez regarder la définition de la table …
Marc.
Hors ligne
\d pg_class évidemment, pas pg_classe
Marc.
Hors ligne
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/
mabase=# \d pg_class
Table "pg_catalog.pg_class"
Column | Type | Modifiers
----------------+-----------+-----------
relname | name | not null
relnamespace | oid | not null
reltype | oid | not null
relowner | integer | not null
relam | oid | not null
relfilenode | oid | not null
relpages | integer | not null
reltuples | real | not null
reltoastrelid | oid | not null
reltoastidxid | oid | not null
relhasindex | boolean | not null
relisshared | boolean | not null
relkind | "char" | not null
relnatts | smallint | not null
relchecks | smallint | not null
reltriggers | smallint | not null
relukeys | smallint | not null
relfkeys | smallint | not null
relrefs | smallint | not null
relhasoids | boolean | not null
relhaspkey | boolean | not null
relhasrules | boolean | not null
relhassubclass | boolean | not null
relacl | aclitem[] |
Indexes:
"pg_class_oid_index" unique, btree (oid)
"pg_class_relname_nsp_index" unique, btree (relname, relnamespace)
Hors ligne
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.
Marc.
Hors ligne
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...
Hors ligne
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…).
Marc.
Hors ligne
C'est quasiment impossible que ce soit le hardware, car c'est une machine virtuelle.
Pour le reste, pas de fsync à off.
Hors ligne
"C'est quasiment impossible que ce soit le hardware, car c'est une machine virtuelle."
La machine virtuelle, elle tourne sur quoi ? 
Marc.
Hors ligne
