Vous n'êtes pas identifié(e).
Pages : 1
Salut,
Après de longues recherches sur le forum ainsi que sur la toile, le problème :
Server doesn't listen
The server doesn't accept connections: the connection library reports
could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432? persiste toujours, je me suis lancé dans la réinstallation du serveur après avoir enregistré le dossier data comme indiqué Ici. Alors après avoir effectué cette démarche, le problème est résolu, je compare le fichier data de l'installation avec celui de sauvegarde, il manque un dossier que je suppose que celui qui contient ma base de données site_officiel sur laquelle est attribuée un rôle avec un nom d'utilisateur tackichi et un mot de passe. Après l'ajout de ce dossier dans le sous dossier base de data, l'erreur décrite auparavant réapparaît.
Merci de m'indiquer s'il existe une méthode pour mettre en ordre ma base de données site_officiel qui contient l'intégrité de mon site web .
Merci !
Dernière modification par Tackichi (06/03/2010 15:06:04)
Hors ligne
Que veux-tu dire par "persiste toujours"? Depuis quand as-tu ce problème? Qu'as-tu fais avant d'avoir ce problème? (apparemment ce n'était pas une nouvelle installation puisque tu dis que la base contenait ton site web...)
Et après la réinstallation, de quel dossier parles-tu (celui que tu as mis dans data/base)???
Hors ligne
Merci pour ta réponse,
1 j'ai pas pu résoudre le problème.
2 il y'a une semaine que je l'avais eu.
3 Je ne sais pas sa cause.
4 Effectivement j'avais le serveur qui tournait normalement sur la machine.
5 un dossier qui porte le nom 16547 qui n'est pas présent dans la nouvelle installation contrairement à l'ancienne.
Hors ligne
Tu décris deux problèmes différents :
A/ Le serveur n'écoutait pas sur l'adresse 127.0.0.1 et le port 5432. Il peut y avoir plusieurs raisons à cela. Peut-être que le serveur PostgreSQL était éteint. Peut-être que la variable listen_adresses étaient mal configurée. Peut-être qu'un pare-feu sur la machine bloque les connexions.
B/ Pour sauvegarder une base de donnée, il faut utiliser la comande pg_dump. Il ne faut JAMAIS copié, ni déplacé un des sous-répertoires qui se trouvent dans le dossier base. Il est certain que si vous copier le dossier 16547 sur votre nouvelle installation le serveur PostgreSQL refusera de démarrer et vous retomberez sur le problème A.
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Merci pour ta réponse,
Non plus, tu n'as pas bien compris mon problème, je reformule mon post :
Il y'a une semaine que mon serveur qui contenait une base nommé site_officiel a cessé de fonctionner en m'affichant ce code d'erreur via pgAdmin :
Server doesn't listen
The server doesn't accept connections: the connection library reports
could not connect to server: Connection refused (0x0000274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432?.
J'ai sauvegardé le répertoire data puis j'ai effectué une réinstallation du serveur, le problème précédent est résolu. Or, quand je compare le fichier data nouvellement créé par l'installation avec celui sauvegardé auparavant, je constate qu'il manque un sous-dossier intitulé 16547 que je suppose que celui qui contient ma base de données site_officiel sur laquelle est attribuée un rôle avec un nom d'utilisateur tackichi et un mot de passe dans le répértoire base
Après l'ajout de ce dossier dans le répertoire base pour mettre en ordre ma base de données site_officiel l'erreur décrite ci-dessus réapparaît de nouveau.
Je souhaite que ça soit clair maintenant, merci !
Dernière modification par Tackichi (06/03/2010 18:51:25)
Hors ligne
Le répertoire 16457, c'est un répertoire qui a été créé dans l'installation précédente, lors de la création de la base de données site_officiel. Malgré tout, ce répertoire fait partie de l'ancien 'cluster' (le répertoire data). Et l'ensemble des fichiers d'un cluster doit être cohérent, c'est à dire qu'on ne peut pas restaurer un répertoire d'un cluster de base de données de façon indépendante du reste du cluster. Les fichiers de données, les journaux binaires, le fichier de contrôle… DOIVENT être cohérents. C'est grâce à celà que PostgreSQL garantit l'intégrité des bases.
C'est aussi pour cela que ce répertoire n'est pas présent à la réinstallation : aucune base n'a été créée puisque le cluster est vierge.
Et c'est aussi vraisemblablement pour cela que 'Connection refused (0x0000274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432?.' : le serveur refuse de démarrer, ce que vous auriez probablement vu si vous aviez consulté les logs. Ce n'est pas parce que vous avez deux fois la même erreur (enfin le même message d'erreur vu du client, qui vous dit simplement qu'il n'y a pas de serveur en face pour répondre à votre requête) que la cause est forcément identique.
Pour revenir au sujet, les posts précédents sont parfaitement pertinents :
- Flo demande des informations sur la manipulation pour essayer de comprendre la cause du problème
- Daamien explique
- la cause du message Connection refused (0x0000274D/10061) Is the server running on host "127.0.0.1" and accepting TCP/IP connections on port 5432?
- et précise que la méthode de backup est très dangereuse et ne garantit absolument pas de pouvoir repartir (ce qui est confirmé par vos différents posts on dirait)
Si vous voulez revoir vos données , vous n'avez à mon avis qu'une solution sûre :
- restaurer entièrement le répertoire data comme il l'était au moment où vous l'avez sauvegardé (vous l'avez fait base éteinte au moins ?)
- essayer de le redémarrer. Si vous avez encore le même message d'erreur, consultez la log (répertoire pg_log du cluster) et donnez nous le message. Là nous pourrons vous aider au lieu de deviner.
Marc.
Hors ligne
Merci pour m'avoir éclaircir la notion des fichiers data.
J'ai effectué la tâche que tu m'as proposé, mais quand je redémarre le serveur toujours la même erreur, et dans le répertoire pg_log le dernier fichier est daté du 24-2-2010 .
Merci
Hors ligne
Aucune erreur nulle part ?
Même pas dans le journal d'évènements windows ?
Marc.
Hors ligne
sur le shell de postgreSql j'ai obtenu l'erreur suivante :
psql: n'a pas pu se connecter au serveur : Connection refused (0x0000274D/10061)
Le serveur est-il actif sur l'hôte « localhost » et accepte-t-il les connexions TCP/IP sur le port 5432 ?or sur les journal d'évènements windows :
2010-03-07 11:03:08 GMTFATAL: bogus data in lock file "postmaster.pid": ""Merci !
Hors ligne
Si PostgreSQL est arrêté, supprimez le contenu du fichier postmaster.pid et essayez de redémarrer PostgreSQL.
Guillaume.
Hors ligne
Bravo gleu !
j'ai supprimé le fichier postmaster.pid, j'ai réglé les droits d'accès au dossier data en l'appropriant à l'utilisateur standard de windows à l'aide de cette commande ajoutée à vista :
takeown /f "C:\chemin_du_dossier"J'ai démarré le serveur et Voilà le fameux postgreSql démarre.
Un grand Merci à Marc Cousin pour son importante intervention.
Merci à vous tous !
Hors ligne
Bonjour et merci pour ce post car cela à également réglé mon problème.
1) Par contre quelqu'un saurait il dans quel cas on peut se retrouver avec un postmaster.pid vide ou corrompu qui empeche le démarrage de postgres?
2) Pour ma part, je pense avoir peut être éteint brutalement la machine sans arréter le service PostGres correctement. Est-ce que cela peut en être la cause?
3) Si je supprime automatiquement le postmaster.pid au démarrage, après ce type plantage par exemple, je risque de perdre des données dans ma base?
Merci à tous
Hors ligne
1) Par contre quelqu'un saurait il dans quel cas on peut se retrouver avec un postmaster.pid vide ou corrompu qui empeche le démarrage de postgres?
Tout arrêt brutal de la base de données (kill du pid sous linux par exemple). En somme ne pas laisser le temps au serveur de supprimer le fichier postmaster.pid
2) Pour ma part, je pense avoir peut être éteint brutalement la machine sans arréter le service PostGres correctement. Est-ce que cela peut en être la cause?
Oui
3) Si je supprime automatiquement le postmaster.pid au démarrage, après ce type plantage par exemple, je risque de perdre des données dans ma base?
cause directe, Non, par répercussion oui, un arret brutal de la base de données peut créer une incohérence dans les fichiers (l'écriture d'un fichier de données qui s'arrête en plein milieu par ex.), ce qui met la base de données en mode récovery (il n'est pas dit que la restauration se terminera correctement).
Hors ligne
Il y a pire pour le 3 : on pourrait, en supprimant le fichier pid, avoir deux jeux de processus attaquant les fichiers de la base en même temps. Corruption garantie.
Normalement, le fichier pid est supprimé automatiquement au démarrage, si aucun processus sur le système n'a le pid indiqué. Mais de temps en temps, ça arrive 
Marc.
Hors ligne
Pages : 1