Discussion :

[CetTer]

Bonjour,


Je suis sur Ubuntu 10.04 (virtualisé sous VM) et ai été confronté à un crash de Postgres 8.4, avec le message d'erreur suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

CEST Fatal: The database system is in recovery mode

précédé par les warnings:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

postgres terminating connection because crash of another process

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
The postmaster has commanded this server process to roll back the current transaction and exit, 
because another server process exited abnormally and possibly corrupted shared memory

Après avoir tué et redémarré tous les processus liés à PostgreSQL, j'ai récupéré la base, apparemment intacte.

D'après ce que j'ai lu, le crash pourrait être liée à un problème sous Linux: quand une requête amène Postgres à empiéter sur un bloc de RAM préalloué pour un autre service (par exemple java), l'OS peut purement et simplement décider de "killer" PostgreSQL.


Ca contredit un peu le troisième message d'erreur fourni par PostgreSQL, qui indique qu'un autre service se serait crashé avant postgres (apparemment pas Tomcat, qui tournait toujours)

Seulement voilà, j'aimerais bien identifier la requête et/ou le service qui a provoqué l'interruption pour être certain de la cause de l'erreur et de la manière de la prévenir. Les logs ne me renseignent que sur l'heure. Est-ce que c'est possible?

[estofilo]

Si c'est l'OOM-killer qui s'est "occupé" d'un process postgres, ce sera mentionné dans le log du noyau linux.
cf /var/log/kern.log sur Ubuntu.

Par ailleurs une remarque sur:

Après avoir tué et redémarré tous les processus liés à PostgreSQL

En principe il ne faut jamais faire ça. Les warnings indiquent que postmaster a géré l'incident et il qu'il n'y avait rien à faire manuellement.

[SQLpro]

Les joies de la virtualisation imbécile des SGBDR !!!!

A relire : http://blog.developpez.com/sqlpro/p8...irtualisation/

A +

[CetTer]

C'est bien oom qui a causé le problème d'après syslog.
Mais le base était bien down hier, pas de connection possible, les sites webs liés morts.
Même le script commandant le service dans /etc/init.d plantait.

J'ai reçu d'autres warning aujourd'hui, sans l'erreur fatale du recovery mode.Le serveur peut en effet faire le rollback et redémarrer seul. Il m'indique qu'un redo a été fait , je présume qu'il s'agît de la transaction arrivée au moment du crash.
Mais ça m'inquiète. Je vais tester une insertion d'un gros volumes de données dans la base dès que j'ai le temps.

Merci pour le lien fort intéressant sur la virtualisation. Pas le choix de ne pas virtualiser, sauf à demander de changer complètement l'infrastructure informatique pour ce cas précis. Ceci dit la base de données n'est pas si grosse (400MB), n'est pas sollicitée par beaucoup de connections simultanées, l'applicatif web n'insère rien dedans, et peut admettre un certain temps de latence.

[estofilo]

Si le noyau tue le process postmaster (le parent dans la hiérarchie des processus postgres), il ne sera plus possible de se connecter à la base jusqu'à redémarrage manuel.

S'il tue un processus fils, le parent gère la situation mais toutes les connexions et transactions en cours vont être annulées par sécurité, du fait que le processus était peut-être en train de modifier la mémoire partagée. C'est ça que signifie le message "postgres terminating connection because crash of another process"

C'est pas vraiment une situation viable pour un système en production. Pour éviter ça,
il y a quelques conseils dans la doc, voir le chapitre Linux Memory Overcommit

Par ailleurs la VM n'a peut-être pas assez de RAM par rapport à ses besoins ou pas du tout de swap alors qu'il faudrait en mettre par sécurité, ou bien encore la config logicielle est inadaptée à la RAM (shared_buffers de postgres trop élevé ou autre service sur-configuré).

[CetTer]

Bonjour,

Le problème était sans doute causé par la swap, qui n'était plus accessible (fichier fstab erroné).

Merci pour vos réponses qui ont aidé à l’identifier.