Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je me rend compte quand j'ai voulu j'ai voulu créer des extension (postgis+dblink) sur une nouvelle base créée sous postgres d'un message:
"ERROR: could not read block 43 in file "base/xxx/yyy" : read only 0 of xxx bytes" de plus je ne peux même pas faire un vacuum full su cette base ni sur la base (postgres). Pour les autres base je peut faire vacuum full mais pas celui ci. Sur internet ils parlent de bug et ils disent de faire une restauration chaose que j'ai faite après un "initdb" en vain.
Pour le bug je ne crois pas car j'ai fait la même opération sur un environnement identique (version linux 'redhat6' et postgesql) je ne sais pas si qq à eu une même galère et qui pourra m'aider.
Merci d'avance
Hors ligne
Bonjour,
cela ressemble plutôt à un problème matériel sur le serveur. Avez-vous eu des soucis disques, ou quelque chose dans la sortie de dmesg ?
Vous pouvez essayer de voir à quoi correspond ce fichier avec la requête suivante :
SELECT * FROM pg_class where relfilenode = yyy, en étant connecté sur la base en question (SELECT * FROM pg_class WHERE oid = xxx pour trouver la bonne base si vous n'en êtes pas sur).
Vous pouvez également voir la taille de ce fichier ou autre problème directement sur le système de fichier du serveur.
Sinon, le serveur en question a été complètement réinitialisé avec un initdb ? Puis restauré ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour, merci rjuju!
Comme indiqué plus haut j'ai supprimer et recréer le cluster postgres via initdb et restaurer les données via pg_basebackup. Pour plus de précision c'est une VM qui ecrit sur du raid 5, 3 disques (pas bien je sais mais je ne suis pas décideur) bref. L'OS redhat6. je na sais pas s'il faut faire un dmesg ou un "tw_cli" moi aussi je me penche sur un pbm matériel mais j'aimerai investir tout les pistes concernant le SGBDR postgres. car la partie système
n'est pas ma responsabilité pourtant ça m’intéresse fortement.
Pour dmesg j'avoue que je ne sais pas tout lire mais si tu pourras m'aiguiller quel information devrai je chercher ça m'aidera énormément.
merci d'avance
Hors ligne
Le problème vient peut-être de la méthode de restauration. La méthode "pg_basebackup" va créer une instance de 0, un initdb est donc inutile. Le pg_basebackup ne devrait pas pouvoir se lancer si le répertoire indiqué par -D n'est pas vide. L'instance démarrée pointe-t-elle bien sur le bon répertoire pg_data ?
Comme ce serveur est restauré à partir d'un autre serveur, il est également possible que ce soit le serveur source qui souffre d'une défaillance. As-tu noté des erreurs dans les journaux applicatifs de postgres (ceux du serveur maître) lors de cette étape ?
Concernant la sortie de dmesg, les messages affichés en cas de problème peuvent être assez variés, mais sont normalement facilement reconnaissable par rapports aux informations "normales". Un "dmesg -l err,crit,alert,emerg" ou "dmesg |grep -i err" (selon l'os) est déjà un bon point de départ.
Julien.
https://rjuju.github.io/
Hors ligne
Votre dernier message est pour le moins étonnant. On ne restaure pas de données avec un pg_basebackup. Ça ne sert à rien de faire un initdb, si c'est pour utiliser une sauvegarde faite avec pg_basebackup. Etc.
En tout cas, votre message d'erreur fait penser à un problème matériel. Donc il faudrait récupérer une sauvegarde (faite avec pg_dump ou pg_basebackup) et essayer de la restaurer sur un autre serveur (avec psql ou pg_restore, ou une simple copie).
Guillaume.
Hors ligne
Bonjour Guillaume,
T'as raison car j'ai oublier (désolé) de préciser que c'est une architecture HA (streaming replication) avec deux machines master/slave. Donc j'ai fait pg_basebackup pour restaurer les données sur l'un des nœuds.
En revanche peux tu (ou julien) me dire ce que je dois chercher dans la sortie de la commande "dmesg"?
Bien à vous
Hors ligne
Pages : 1
