Vous n'êtes pas identifié(e).
Bonjour,
Nous utilisons PostgreSQL version 9.6 sur un OS linux centOS.
En regardant les log je vois des messages d'erreur : ERROR: could not stat file "pg_xlog/0000000100000AF800000094": No such file or directory
La base est en marche toujours, jusqu'ici il n'y a pas de problème mais ce message dans les logs me laisse penser, quels peuvent bien en être la cause de cet erreur ?
Auriez vous une réponse à cette question ?
Merci de votre attention
Hors ligne
En soit, ça ne sent pas bon. Ça correspond aux journaux de transactions et s'il le cherche, c'est qu'il en a besoin. Le truc bizarre, c'est qu'il devrait ne pas fonctionner correctement après ça. Je dirais même qu'il devrait planter. Quels sont les messages autour de celui-là ?
Guillaume.
Hors ligne
Salut,
Autour de celui-là existe pas de messages particulier, seulement les requêtes qu'il execute.
Sinon un exemple de message complet avec statement est :
2019-01-28 15:28:21 EAT [P:32755][S:5c4eefa9.7ff3][T:0][A:[unknown]] (postgres@[local]): [4-1] ERROR: could not stat file "pg_xlog/00000001000010D40000007E": No such file or directory
2019-01-28 15:28:21 EAT [P:32755][S:5c4eefa9.7ff3][T:0][A:[unknown]] (postgres@[local]): [5-1] STATEMENT:
2019-01-28 15:28:21 EAT [P:18381][S:5c4cba22.47cd][T:0][A:] (@): [1110-1] LOG: checkpoint complete: wrote 189547 buffers (2.6%); 0 transaction log file(s) added, 44 removed, 55 recycled; write=209.352 s, sync=0.094 s, total=209.701 s; sync files=502, longest=0.007 s, average=0.000 s; distance=1245287 kB, estimate=1245287 kB
Ce qui est bizarre c'est si tu dis qu'il en a besoin alors pourquoi les wall n'y sont plus. Et est ce que çà n'a pas influence avec la cohérence des transactions ?
Hors ligne
Le PID 32755 correspond à quel processus ?
Le principal problème est en cas de crash. Si des journaux sont manquants, la cohérence des fichiers de données n'est plus assurée. De ce fait, le moteur s'arrête tout seul.
Mais bon, difficile de dire plus avec seulement ce bout de log. S'il ne balance pas de messages PANIC, c'est que ça ne doit pas être bien grave. Mais j'avoue que je ne comprends pas comment un journal de transactions manquant pourrait ne pas être grave.
Guillaume.
Hors ligne
Le processus du pid n'est plus trouvable. Et non pas de message PANIC.
En fait il existe un archive_command qui fait un rsync des wall mais je ne voit pas trop pourquoi si c'est du à cà ?
Hors ligne
S'il ne fait qu'un rsync, ce n'est pas ça.
Guillaume.
Hors ligne
Es ce que ce message n'est pas lié à un problème d'archivage ? avez vous un fichier pg_xlog/archive_status/00000001000010D40000007E.ready de présent ?
Hors ligne
bah oui vu que le mode archivage est activé des wall.ready sont présent
Hors ligne
Si le fichier .ready est présent mais pas le wal lié, ça créée ce genre de message quand le moteur essaye d'archiver
Hors ligne
est-ce que le fichier pg_xlog/00000001000010D40000007E est présent autre part (répertoire de sauvegarde, archivage, support autre, etc...) ?
Si oui il faudrait le recopier dans pg_xlog pour que l'archivage puisse reprendre.
Sinon, alors là gros problèmes en perspective.
Cordialement,
Sébastien.
Hors ligne
Merci pour vos réponses,
pitpoule , ruizsebastien > réfléchis comme tel je pense que vous aviez peut être raison, mais je ne vois pas comment expliquer qu'un wall.ready est présent SANS le wall dans pgxlog, alors que c'est de part le wall qu'il detecte qu'il fait un .ready et par la suite un .done lorsque le wall sera copié ???
Hors ligne
la vrai question et donc pourquoi et comment le wall ne serait plus présent alors que dans archive_status il y aurait un wall.ready ??
Hors ligne
pour l'instant il faudrait trouver ce wal manquant et seulement après essayer de trouver la cause de son absence.
J'imagine qu'à l'heure actuelle votre repertoire pg_xlog se rempli ?
Cordialement,
Sébastien.
Hors ligne
Merci pour vos réponses,
pitpoule , ruizsebastien > réfléchis comme tel je pense que vous aviez peut être raison, mais je ne vois pas comment expliquer qu'un wall.ready est présent SANS le wall dans pgxlog, alors que c'est de part le wall qu'il detecte qu'il fait un .ready et par la suite un .done lorsque le wall sera copié ???
Une raison toute bête mais qui malheureusement arrive de temps en temps: quelqu'un l'a supprimé :s.... ou un problème matériel ?
Vous pouvez supprimé le fichier .ready, l'archivage va repartir... mais il faudra sûrement relancer un backup dans la foulée car tous les backups qui auraient besoin de ce fichier seront inexploitables.
Hors ligne
En effet le repertoire pg_xlog a commencé à se remplir hier mais je ne sais pas si çà en est la cause ou pas. Pour y remedier on a mit archive_commande = /bin/true pour libérer l'espace. Un dump regulier est lancé toutes les nuits.
Sauriez vous donc quelle pourrait être la cause de la disparition de ce wall ?
Hors ligne
Non, et on ne peut pas le savoir. Comme le dit pitpoule, ça peut être qqn qui l'a supprimé, ça peut être un problème matériel. Ça peut aussi être une erreur dans un script. Etc.
Guillaume.
Hors ligne
