Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous utilisons postgresql-9.4 sur un serveur linux. Dans ce SGBD existe la base de données postgres, et notre base de données "X" qui elle est utilisée par une application.
Nous constatons que cela fait 2 fois successives environ à chaque début de semaine que notre base de données "X" devient inaccessible. Je m'explique:
- le service postgresql est en marche
- la base postgres sous postgresql est accessible
- Cependant, notre base de données "X" sous postgresql, elle, est inaccessible
Après redémarrage du service postgresql, apparemment le problème est règlé et notre base de données "X" redevient accessible à nouveau.
Pour l'instant, pour contourner le problème nous envisageons de programmer le redémarrage du service à chaque fin de semaine.
Toutefois, auriez vous une explication à ce qui peut être la cause de ce problème ? Et quelle solution optimale serait la bonne ?
Nous avions remarqué que le log mentionne des informations comme suit:
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.474 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
Aviez vous une idée d'où pourrait provenir le problème ?
Merci déjà de l'attention que vous porteriez à ce sujet.
Dans l'attente de vous lire 
Hors ligne
Pas d'idée particulière (en dehors que, en effet, c'est un problème... reste à savoir d'où il vient et comment le corriger). Les messages ici ne me disent rien. Il serait bon de les configurer en anglais, ce serait plus simple à rechercher sur internet.
Avez-vous essayé de vous connecter avec psql au moment où l'application n'arrivait plus à se connecter ?
Guillaume.
Hors ligne
Bonjour,
Comment se connecte l'application ?
Car le message d'erreur laisse à penser que la déconnexion est faite par le client (Connexion ré-initialisée par le correspondant).
Cordialement,
Sébastien.
Hors ligne
Merci de vos réponses.
gleu> Au moment où l'application n'arrivait pas à se connecter, on a pas essayer avec psql mais par contre l'équipe à essayer de se connecter via pgadmin. Et à ce stade d'inaccessibilité, avec pgAdmin, lorsqu'on entre sur la base, là pgAdmin se met à loader du coup. Et d'ailleurs, l'interface de l'application elle même renvoie une erreur comme quoi "la base de données n'est pas en ligne" au moment de l'authentification.
ruizsebastien> L'application utilise glassfish qui elle utilise le pilote jdbc pour se connecter à la base postgresql.
Sinon, il existe une tache planifiée lancée chaque samedi soir pour faire une reindexation de la base. Est ce que cela pourrait en être la source du problème? Je ne pense pas en tout cas vu que je n'ai pas le souvenir d'avoir eu ce genre de problème avant. Et normalement, la reindexation devrait déjà être bien finie avant le Lundi matin.
Hors ligne
- pouvez vous voir avec vos admins system/réseau s'il n'y a pas de problèmes réseau entre le serveur de l'application et celui de l'instance
- pouvons nous avoir les messages juste au dessus "2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant"
Cordialement,
Sébastien.
Hors ligne
Une réindexation ne poserait pas ce genre de problèmes. Vous avez d'autres messages dans le log de PostgreSQL ? et quel est le message d'erreur exact au niveau du client ?
Guillaume.
Hors ligne
A priori il n'y a pas de problème réseau entre le serveur d'appli et celui de l'instance.
Voici les extraits de logs juste avant < 2017-04-24 06:23:19.473 EAT >
< 2017-04-24 06:02:00.357 EAT >DÉTAIL: paramètres : $1 = 'DECISION_VALIDATION_XML', $2 = '80'
< 2017-04-24 06:02:00.365 EAT >LOG: durée : 5.087 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.365 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_GR_PAR', $2 = '80'
< 2017-04-24 06:02:00.379 EAT >LOG: durée : 11.021 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.379 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_META_IDENTIFICATOIRES', $2 = '80'
< 2017-04-24 06:02:00.392 EAT >LOG: durée : 9.677 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.392 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_META_DECISION_ANTERIEURE', $2 = '80'
< 2017-04-24 06:02:00.403 EAT >LOG: durée : 8.403 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.403 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ID_META_SECONDAIRE', $2 = '80'
< 2017-04-24 06:02:00.415 EAT >LOG: durée : 8.810 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.415 EAT >DÉTAIL: paramètres : $1 = 'DECISION_ANONYMISATION_MANUAL', $2 = '80'
< 2017-04-24 06:02:00.426 EAT >LOG: durée : 8.572 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.426 EAT >DÉTAIL: paramètres : $1 = 'DECISION_SELECTION_ANONYMISATION', $2 = '80'
< 2017-04-24 06:02:00.437 EAT >LOG: durée : 9.289 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.437 EAT >DÉTAIL: paramètres : $1 = 'DECISION_LAYERS_CONTROL', $2 = '80'
< 2017-04-24 06:02:00.455 EAT >LOG: durée : 3.159 ms exécute <unnamed>: SELECT * FROM get_free_prod_task($1, $2)
< 2017-04-24 06:02:00.455 EAT >DÉTAIL: paramètres : $1 = 'REPRISE_CORR_COUCHES', $2 = '80'
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.473 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
< 2017-04-24 06:23:19.474 EAT >LOG: n'a pas pu recevoir les données du client : Connexion ré-initialisée par le correspondant
Le message d'erreur exact au niveau de l'appli client lors de l'authentification est celui ci:
>>> Erreur: La base de données n'est pas en ligne ? [A timeout has occured. If you were establishing a connection, increase Timeout value in ConnectionString or in your NpgsqlCommandobject]
Hors ligne
Bonjour,
Donc ça sent quand même le problème dans votre serveur d'application.
Comme indiqué par le message d'erreur, jouez avec le timeout.
Cordialement,
Sébastien.
Hors ligne
Bonjour,
ruizsebastien> Mais si c'est un problème vis à vis de l'application client, pourquoi çà ne s'était pas produit depuis ? Je tiens à informer quand même que historiquement, on a migré la base de données de postgresql 8.4 windows vers postgresql 9.4 linux il y avait environ 1 moi de cela.
Et ce problème de connectivité à la base s'est apparu depuis ses 2 dernières semaines.
Hors ligne
Ça peut être un problème de réseau, de firewall, etc, etc.
Guillaume.
Hors ligne
Oui, il se pourrait bien, en tout cas le problème semble ne plus survenir.
Merci à tous, pour ces réponses et accompagnements et bon week end.
Hors ligne
Pages : 1
