Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je travaille sur une version 8.4.2 sous Cent-OS 5.2.
Je viens de lancer la commande : pg_ctl stop et ............. failed
pg_ctl: server does not shut down
Dans le fichier de log, j'ai ces lignes :
2623 2010-03-04 10:16:25 CET 2 LOG: received smart shutdown request
2629 2010-03-04 10:16:25 CET 2 LOG: autovacuum launcher shutting down
[local] 23938 2010-03-04 10:28:21 CET /usr/local/pgsql/bin/postmaster 1 FATAL: the database system is shutting down
[local] 23943 2010-03-04 10:28:48 CET /usr/local/pgsql/bin/postmaster 1 FATAL: the database system is shutting down
J'essaye de me connecter : psql template1 : psql: FATAL: the database system is shutting down
Je fais un pg_ctl status : pg_ctl: server is running (PID: 2623)
Quelqu'un à t'il déjà rencontré ce problème ?
Que faut-il faire ?
Merci pour vos réponses.
Hors ligne
Bonjour,
Vous avez fait une demande d'extinction propre de la base, qui n'arrive pas à se terminer. C'est très rare, et je ne pense pas qu'en trouver la cause vous intéresse particulièrement.
Le plus simple pour vous, c'est d'éteindre brutalement la base :
pg_ctl -m immediate stop
Le -m immediate tue les processus PostgreSQL.
Vous ne perdrez aucune donnée, tout étant journalisé. Le redémarrage prendra simplement quelques secondes supplémentaires, le temps que PostgreSQL réapplique les journaux en cours.
Marc.
Hors ligne
Bonjour Marc,
J'ai fait le pg_ctl -m immediate stop, puis redémarrer le serveur. Tout va bien. Merci.
Faut-il s'inquiter ? étes-vous sûr qu'en aucun cas il n'y a de perte de données ? y-a-t'il un Bug ? la version 8.4.2 ?
Merci pour votre réponse.
Hors ligne
Sans option, le « pg_ctl stop » demande un arrêt intelligent à PostgreSQL. Ce qui signifie que PostgreSQL va interdire les nouvelles connexions mais attendre gentiment que les connexions en cours s'arrêtent d'elles-même. Tant qu'elles ne le font pas, le moteur ne peut pas s'arrêter.
Généralement, le mode smart ne doit pas être utilisé. On lui préférera le mode fast (rapide). Dans ce cas, PostgreSQL coupe les connexions clients et s'arrête proprement.
Si vous utilisez le mode immediate (comme l'a proposé à tort Marc 
), PostgreSQL coupe les connexions et s'arrête brutalement. Autrement dit, tout ce qui se trouvait modifié dans la mémoire cache de PostgreSQL n'est pas placé dans les fichiers de données. Il n'y a pas non plus de CHECKPOINT dans le journal de transactions courant. Si bien qu'au démarrage, PostgreSQL découvre l'état incohérent et va relire les journaux de transactions pour remettre d'aplomb les fichiers de données.
Tout ça pour dire que le mode smart n'est généralement pas à utiliser. Vous l'avez utilisé, ce n'est pas grave, mais ça explique pourquoi PostgreSQL n'a pas pu s'arrêter immédiatement comme vous le pensiez. Vous auriez dû faire un arrêt en mode fast pour que l'arrêt soit rapide et propre.
Bref, pour répondre simplement à vos questions :
faut-il s'inquiéter ? Non.
étes-vous sûr qu'en aucun cas il n'y a de perte de données ? Oui.
y-a-t'il un Bug ? Non.
la version 8.4.2 ? est certainement une version très stable et très performante.
Guillaume.
Hors ligne
Aucune inquiétude à avoir. En aucun cas il n'y a perte de données. Quand PostgreSQL vous dit qu'il a commité, la donnée est dans les journaux et ne peut plus être perdue.
Habituellement ce que vous avez eu se produit parce que postgresql attend gentiment que tout ce qu'il fait se termine. Il devait y avoir une opération en cours qui le bloquait.
Par ailleurs, le mode par défaut (smart) attend que toutes les sessions se soient déconnectées avant de fermer, il suffit que vous en ayez eu une en cours pour avoir le problème. C'est d'ailleurs pour cela qu'il y a le mode fast, qui fait une extinction 'propre' mais sans attendre que les sessions se soient déconnectées.
Marc.
Hors ligne
Il est trop rapide ce gleu
Marc.
Hors ligne
Merci messieurs pour votre rapidité et les explications claires.
Hors ligne
et bien bravo vous lui avez enlever une grosse épine aux pieds
Hors ligne
Pages : 1
