Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je tente de redemarrer mon serveur postgresql par le biais de
service postgresql-9.4 start
puis je regarde le statut
service postgresql-9.4 status et j'ai le probleme :
postgresql-9.4 dead but pid file exists
J'ai bien un fichier postmaster.pid dans /var/lib/pgsql/9.4
et il a des droits utilisateur/groupe en root , deja est-ce normal ?
Faut il le passer en droits postgres comme les autres fichiers ?
Faut-il le supprimer puis redemarrer ?
Merci d'avance
Hors ligne
victoire,
bon j'ai supprimé le fichier postmaster.pid
passer en ligne de commande su postgres et utilisé :
/usr/pgsql-9.4/bin/pg_resetxlog -f /var/lib/pgsql/9.4/data
redémarré le serveur postgres et ca marche !!!!!
source : https://www.windows8facile.fr/postgresq … nt-record/
Hors ligne
Bon, alors, surtout, ne jamais jamais jamais utiliser pg_resetxlog/pg_resetwal à moins de savoir à quoi ça sert. Là, il y a de fortes chances que vous ayez corrompu votre instance. Comme le dit la doc :
After running this command, it should be possible to start the server, but bear in mind that the database might contain inconsistent data due to partially-committed transactions. You should immediately dump your data, run initdb, and reload. After reload, check for inconsistencies and repair as needed.
Après avoir utilisé cet outil, un seul bon conseil, sauvegardez vos bases avec pg_dump, recréez votre instance, puis restaurez vos bases.
Guillaume.
Hors ligne
+1, surtout quand vous utilisez comme source un article qui parle d'un problème qui n'a à priori rien à voir.
En l'état il est à peu près sûr que vous ayez corrompu au moins quelques lignes, probablement beaucoup, sans moyen simple de détecter le problème.
J'irais plus loin que Guillaume : une restauration d'une précédente sauvegarde s'impose. Sauvegarder et restaurant l'instance actuelle pourrait détecter certaines formes de corruptions, mais pas toutes.
Julien.
https://rjuju.github.io/
Hors ligne
J'ajoute que le fichier postgresql.conf , je l'ai ouvert avec un editeur simple de texte et bizarrement il y avait
des symboles ésotériques bizarres ; donc je l'ai remplacé par un fichier sain.
bon ok dans ce cas là avec l'erreur "postgresql-9.4 dead but pid file exists ",
quel aurait été la bonne procédure à faire pour résoudre le probleme ?
Hors ligne
J'ajoute que le fichier postgresql.conf , je l'ai ouvert avec un editeur simple de texte et bizarrement il y avait
des symboles ésotériques bizarres ; donc je l'ai remplacé par un fichier sain.
Cela pourrait être un signe de corruption sur vos données.
bon ok dans ce cas là avec l'erreur "postgresql-9.4 dead but pid file exists ",
quel aurait été la bonne procédure à faire pour résoudre le probleme ?
Regarder dans les logs et trouver la raison pour laquelle postgres n'a pas démarré et/ou s'est arrêté brutalement.
Julien.
https://rjuju.github.io/
Hors ligne
dans les logs j'avais repéré ca :
< 2021-06-14 20:44:25.782 CEST >LOG: startup process (PID 9520) was terminated by signal 6: Aborted
< 2021-06-14 20:44:25.782 CEST >LOG: aborting startup due to startup process failure
< 2021-06-14 20:47:26.308 CEST >LOG: database system was interrupted; last known up at 2021-06-14 16:39:40 CEST
< 2021-06-14 20:47:26.399 CEST >LOG: invalid primary checkpoint record
< 2021-06-14 20:47:26.399 CEST >LOG: record with zero length at 1022/3C3D2AE8
< 2021-06-14 20:47:26.399 CEST >LOG: invalid secondary checkpoint record
< 2021-06-14 20:47:26.399 CEST >PANIC: could not locate a valid checkpoint record
Hors ligne
À priori je dirais que vos données étaient corrompues. Vous devriez trouver des traces de ça quelque part dans vos autres logs (dmesg, messages...). pg_resetxlog n'a fait qu'autoriser postgres à démarrer malgré le problème et caché les premiers signes de corruptions (en augmentant la quantité de données corrompues probablement). Vous devez chercher la raison de ce problème, le régler, et restaurer les données depuis votre dernière sauvegarde valide.
Julien.
https://rjuju.github.io/
Hors ligne
recreer ma base et importer une ancienne sauvegarde,
je peux faire ca avec pgadmin ?
Hors ligne
J'imagine. Mais vous faites des sauvegardes que vous n'avez jamais essayé de restaurer?
De plus, vous passez à côté de l'urgence absolue : trouver la cause de cette corruption et corriger le problème. Sans quoi vous allez restaurer vos données, et donc perdre les données modifiées entre temps, et subir de nouvelles corruptions.
Julien.
https://rjuju.github.io/
Hors ligne
qu'est qui est corrompu au juste ?
une base de données precise ou carrément tout le cluster de bases de données ?
Hors ligne
Aucune idée, et il est de toutes façons en général impossible de donner une réponse les corruptions pouvant être silencieuses. Cela peut aller de "absolument rien" à "absolument tout".
La seule chose que je peux dire est qu'au minimum le fichier postgresql.conf et certains journaux de transactions étaient corrompus avant d'exécuter le pg_resetxlog. La corruption engendrée par le pg_resetxlog dépend de l'activité depuis le dernier checkpoint.
Julien.
https://rjuju.github.io/
Hors ligne
de toute facon, cette base était secondaire et n'est pas utilisée réellement,
ce cas m'a permis d'être confronté à cette éventualité et de procéder aux mesures adéquates !
C'est en faisant des erreurs qu'on s'améliore !
Hors ligne
C'est une relativement bonne nouvelle. Attention cependant si d'autres instances utilisent le même stockage, vous pourriez avoir le même problème sans vous en être encore rendu compte.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
