Vous n'êtes pas identifié(e).
MASTER SETUP
Step1: paramétrage postgresql.conf
wal_level = replica
max_wal_senders = 8
max_wal_size = 1GB
hot_standby = on
Step2: Creation de l'utilisateur pour la replication
Step3: Parametrage de pg_dba.conf
SLAVE SETUP
Step4: Arrêt de l'instance
Step5: Restauration du master pour créer la replique avec >>> pg_basebackup
Step6: Copie/coller du postgresql.conf du master vers le slave
Step7: Creation du recovery.conf
standby_mode = on
primary_conninfo = 'host=masterhost user=userrepl'
Step8: Démarrage du slave
>>>> Je précise ici qu'on a mis archive_command = '' sur le maitre
Je pense que le problème vient d'ici, on a désactivé l'archive_command sans pour autant mis archive_mode = 'off' donc archive_mode toujours activé les fichiers dans pg_xlog/archive_status sont tous mit en .ready et en attente de copie par archive_command, du coup les wal dans pg_xlog s'accumulent et prennent de l'espace.
Pour solutionner nous pensons à mettre archive_mode = 'off' puis redémarrer le master. Monter pg_xlog dans le serveur de replique et inserrer pg_archivecleanup dans recovery.conf pour supprimer les wal qui ne sont plus utiles dans le repertoire pg_xlog monté.
Qu'en pensez vous ? Nous allons faire un jeu de test.
select * from pg_stat_archiver >>
archived_count last_archived_wal last_archived_time failed_count last_failed_wal last_failed_time stats_reset
0 0 2017-07-15 12:41:24.872644+00
Merci pour cette réponse.
C'est-à-dire ? Parce que dit comme ça ça ressemble à une très très mauvaise idée. Les WALs doivent être archivés avant d'être rejoué.
>>>C'est à dire que le système actuel n'utilise pas d'archive command dans postgresql.conf.
Pour les autres information:
select * from pg_stat_archiver >>
archived_count last_archived_wal last_archived_time failed_count last_failed_wal last_failed_time stats_reset
0 0 2017-07-15 12:41:24.872644+00
select * from pg_replication_slots >> Aucun resultat
wal_keep_segments = 100
Effectivement, je crois que vous aviez raison. Faudrait peut être diminuer wal_keep_segments ? Justement puisque le système n'utilise pas archive_command on a préféré définir wal_keep_segments à 100.
Pouvez vous conseiller sur la bonne solution à prendre ?
Bonjour,
Nous travaillons avec un postgresql-9.6 sur un environnement linux.
J'ai monté une base replique sur un autre serveur en mode streaming en utilisant les paramètres de postgres de façon à ce que le slave joue les WAL directement depuis l'emplacement pg_xlog de serveur maitre. C'est bon, la réplication marche, mais, le problème étant que les fichiers dans pg_xlog du serveur maitre ne sont pas effacés et s'accumulent, ce qui bouffent beaucoup d'espace disque. Le contenu du fichier recovery.conf est comme ceci:
standby_mode = 'on'
primary_conninfo = 'host=host_maitre port=port_maitre user=rep password=reppassword'
trigger_file = '/tmp/postgresql.port.trigger.5434'
Est ce normal que ces fichiers wal dans pg_xlog ne sont pas supprimés, comment fait on pour y remédier car on commence à manquer d'espace disque.
J'ai pensé à utiliser pg_archivecleanup et insérer cette commande dans le recovery.conf. Mais je ne crois pas que pg_archivecleanup dispose d'option pour se connecter au serveur maitre depuis le slave ?
Pouvez vous nous aider sur ces points ?
Merci d'avance.
- Disque ext4 partitionné en GPT
- RAM 128Go
Config postgres:
"application_name"-----"pgAdmin III - ??diteur de requ??tes"
"archive_command"-----"rsync -a %p postgres@fsd3.numen.mg:/part_2/db_replica/wal_archives/serv1-9.4.5/%f"
"archive_mode"-----"on"
"bytea_output"-----"escape"
"checkpoint_segments"-----"32"
"client_encoding"-----"UNICODE"
"client_min_messages"-----"notice"
"data_checksums"-----"off"
"DateStyle"-----"ISO, MDY"
"default_text_search_config"-----"pg_catalog.french"
"dynamic_shared_memory_type"-----"posix"
"effective_cache_size"-----"39GB"
"hot_standby"-----"on"
"huge_pages"-----"try"
"lc_collate"-----"fr_FR.UTF8"
"lc_ctype"-----"fr_FR.UTF8"
"lc_messages"-----"en_US"
"lc_monetary"-----"en_US"
"lc_numeric"-----"en_US"
"lc_time"-----"en_US"
"listen_addresses"-----"*"
"log_autovacuum_min_duration"-----"0"
"log_checkpoints"-----"on"
"log_connections"-----"on"
"log_destination"-----"stderr"
"log_directory"-----"/data01/PostgreSQL/9.4.5/pg_log/log_srvl1_5452"
"log_disconnections"-----"on"
"log_filename"-----"postgresql-%Y-%m-%d.log"
"log_line_prefix"-----"%t [P:%p][D:%d]: [%l-1] "
"log_lock_waits"-----"on"
"log_min_duration_statement"-----"500ms"
"log_rotation_age"-----"1d"
"log_rotation_size"-----"10MB"
"log_statement"-----"none"
"log_temp_files"-----"0"
"log_truncate_on_rotation"-----"off"
"logging_collector"-----"on"
"maintenance_work_mem"-----"7680MB"
"max_connections"-----"400"
"max_stack_depth"-----"2MB"
"max_wal_senders"-----"5"
"port"-----"5452"
"random_page_cost"-----"2"
"server_encoding"-----"UTF8"
"server_version"-----"9.4.5"
"shared_buffers"-----"15GB"
"TimeZone"-----"localtime"
"transaction_deferrable"-----"off"
"transaction_isolation"-----"read committed"
"transaction_read_only"-----"off"
"wal_buffers"-----"16MB"
"wal_keep_segments"-----"100"
"wal_level"-----"hot_standby"
"work_mem"-----"480MB"
Salut,
Gleu> Oui les CPU sont largement utilisés quand il existe beaucoup de requêtes en lancement (en phase de production). Donc tu veux dire que le serveur (le CPU) est en surcharge ? Qu'il faudrait peut être migré quelque bases dans un autre serveur, ou quel action d'amélioration peux tu me conseiller ?
****
En fait entre parenthèse j'aimerai savoir si possible, analyze recolte les statistiques pour être utilisé par la suite par l'optimisateur de requête, aussi, est ce que "explain analyze" récolte aussi les statistiques ou lance t elle tout simplement la requête en affichant son parcours et ses coûts. En gros, est ce que explain analyze hérite elle aussi des mécanismes de la commande ANALYZE ?
Je n'ai pas encore eu l'occasion d'utiliser vmstat au moment du lenteur aujourd'hui. Sinon, si çà peut aider, le résultat d'un htop seront un peu pareil à comme ceci:
1 [||||||||||||||||||||||||||||||||||||||97.5%] 7 [||||||||||||||||||||||||||||||||||||||91.8%] 13 [||||||||||||||||||||||||||||||||||||||95.6%] 19 [||||||||||||||||||||||||||||||||||||||95.0%]
2 [||||||||||||||||||||||||||||||||||||||96.9%] 8 [||||||||||||||||||||||||||||||||||||||93.2%] 14 [||||||||||||||||||||||||||||||||||||||96.9%] 20 [||||||||||||||||||||||||||||||||||||||94.4%]
3 [||||||||||||||||||||||||||||||||||||||99.4%] 9 [||||||||||||||||||||||||||||||||||||||91.3%] 15 [||||||||||||||||||||||||||||||||||||||96.9%] 21 [||||||||||||||||||||||||||||||||||||||95.7%]
4 [||||||||||||||||||||||||||||||||||||||96.2%] 10 [||||||||||||||||||||||||||||||||||||||95.7%] 16 [||||||||||||||||||||||||||||||||||||||90.7%] 22 [||||||||||||||||||||||||||||||||||||||94.4%]
5 [||||||||||||||||||||||||||||||||||||||95.6%] 11 [||||||||||||||||||||||||||||||||||||||85.6%] 17 [||||||||||||||||||||||||||||||||||||||96.2%] 23 [||||||||||||||||||||||||||||||||||||||92.5%]
6 [||||||||||||||||||||||||||||||||||||||95.0%] 12 [||||||||||||||||||||||||||||||||||||||95.0%] 18 [||||||||||||||||||||||||||||||||||||||88.3%] 24 [||||||||||||||||||||||||||||||||||||||86.2%]
Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||30673/129190MB] Tasks: 755, 231 kthr; 32 running
Swp[|||||| 3416/61033MB] Load average: 52.17 55.64 46.91
Uptime: 74 days, 02:00:17
***********************
Par ailleurs, j'ai lancé un EXPLAIN(buffers,analyze) de la requête qui subissait une lenteur et effectivement j'ai vu que postgresql utilisée une partie de bloc de disque pour avoir les résultats. Comme ex: Buffers: shared hit=167859 read=14243 et bien sur , plus il utilisise de disque plus la durée d'execution de la requête est longue. Puis, une fois la requête executée elle revient à son temps d'execution normale avec une lecture seulement dans le cache cette fois ci, avec Buffers: shared hit=214390. Mais la vrai question est pourquoi la requête tout d'un coup à besoin de lire dans les blocs pour s'executer, ou est ce que c'est lié au concurrence entre les instances, que j'ai mentionné plus haut ?
Bonjour, je relève le sujet car je pense que les attentes sur les verrous sont des conséquences mais pas de causes.. Puisque ces attentes n'apparaissent qu'à 3/4 fois par jour (ennuyant bien sur), mais ces attentes sont dus je pense à une variation soudaine de la durée d’exécution des requêtes:
- Soit à cause du chemin du planner qui à changer ?
- Soit à cause du charge du serveur énorme.
Mais pourquoi ???
Car en effet, la base est installée dans une instance. Or sur le serveur physique (128Go de RAM) il y existe 3 instances qui elles aussi conservent des dizaines/ vingtaines de base de données (certaines de grande tailles > 200Go, et d'autres petites). Ce qui me laisse à penser que peut être le serveur n'arrive pas à suivre les demandes. Que les instances se bouffent les ressources entre elles peut être? Ce qui va entrainer une réservation de cache par d'autres instances, qui pénaliseront les autres instances surtout les grandes bases, et qui va ensuite entrainer la lenteur de la requête , non ???
Est ce que vous pensez que cette théorie est plausible ? Une remarque toute fois, c'est surtout les grandes bases qui subissent ces lenteurs soudaines de requêtes et après genre 5minutes, les requêtes reprennent son rythme d'execution normale !!!
Pour les logs, rien d'incroyable, mis à part les logs style attentes/acquisition de verrous suite à un laps de temps.. ce qui je pense n'étant pas la cause mais la conséquence ici , non ???
Svp, merci de porter votre attention sur ce sujet , car je ne trouve pas d'autres explications alors que le problème est assez énervant et devrait être résolu, alors comptant sur vos soutiens et idées pour aider 
Après avoir revérifier les logs, il s'agit surement de problème de verrou.
Mais ce qui m'étonne toujours c'est que pourquoi existe il cette attente de verrou, pourquoi la durée d'execution de la requête détentive du verrou vire t elle de 1 sec à 10 minutes ?
Bien vu, et merci pour cette réponse, là je suis d'accord. Ce qui m'étonne toute fois, c'est que les durées d'attentes sont de 10 minutes ou plus, alors que la requête utilisant SELECT FOR UPDATE elle met 1 à 2sec en moyenne à s’exécuter. Par ailleurs, j'ai eu la chance d'avoir pu visualiser le phénomène hier sur l'état du serveur dans pgAdmin. La requête s’exécute et ne se termine pas au moment prévu, son temps d’exécution augmente, puis viens une autre requête avec la même situation, et puis une autre et ainsi de suite.. Pourtant, après vérification il n'existe pas de blocage entre ces requêtes donc je suppose qu'ici il n'y a pas d'attente de verrou non ? Et pourtant c'est requêtes s'accumulant qui normalement met 1 ou 2 sec à s’exécuter ne se terminent qu'après 10 min ou plus, elles se terminent tous à peu près en même temps après mais toute fois avec 1 sec d’écart à peu près.
Est ce toujours un problème de verrou ou d'où pourrait provenir le problème? Est ce que par hasard il y aurait il une liaison avec les ecritures checkpoint, un paramétrage peut être mal configuré, on a checkpoint_segments = 64 avec checkpoint_completion_target = 0.8 ?
Bien à vous
Qu'entendez vous par métriques systèmes et postgres ?
En ce qui concerne les log postgres, il y a pas trop de piste, seulement des messages du genre :
LOG: process 52694 still waiting for ShareLock on transaction 53543073 after 8000.051 ms
DETAIL: Process holding the lock: 52320. Wait queue: 52694.
CONTEXT: while locking tuple (558553,3) in relation "object_item"
Ce qui est assez normale vu que, les requêtes sont en fil d'attentes.
Et sinon les logs figurent aussi des messages du genre:
LOG: process 52839 acquired AccessExclusiveLock on tuple (558590,3) of relation 7539547 of database 16384 after 642909.003 ms
CONTEXT: SQL statement "SELECT id FROM numenvault.Object_item WHERE id = $1 FOR UPDATE"
>>> Ici, les requêtes retournent à leur temps d'execution normale
Sinon, à part çà les logs ne montrent pas grand chose, seulement les durées d’exécution de requêtes et les logs de connections et de déconnections.
>>>>> Ce qui m'étonne c'est que qu'est ce qui fait que la durée d’exécution des requêtes augmentent elles tout d'un coup, passage d'1seconde en 10 minutes soudainement et revient à la normale après? C'est comme si le planner a changé de chemin ou je ne sais pas ?
Est ce que ceci y ait déjà survenu chez vous, avez vous une avis sur le sujet ?
Je tiens toutefois à signaler que la taille des bases de données dont je parle ici atteigne les 400Go ou plus.
Bonjour à tous,
Nous utilisons postgresql 9.4 sur un environnement linux, et nous constatons qu'il arrive dés fois, environ 1,2,5 fois par jour un embouteillage soudaine des requêtes sur le serveur. Cela se produit durant 10 minutes ou 15 minutes, les requêtes deviennent aussitôt lentes (si par exemple la requête s’exécute en 1 seconde normalement elle se fige et ne se termine pas durant ce temps) tout à coup et ne se termine pas durant cette durée, aussi les requêtes commencent alors à s'accumuler durant cette période et la charge du serveur qui pourrait commencer à s'augmenter également au niveau des CPU. Puis après attente, on constate que l'embouteillage est fini, et les requêtes se finissent soudainement et reprend son durée d’exécution normales.
Je tiens à remarquer qu'il n'y a pas blocage entre les requêtes, ou sinon seulement 4 ou 7 requêtes bloquantes sur 65 requêtes qui s'accumulent. Le blocage ne s'apparait qu'après, ie que vu que les requêtes s'accumulent entre elles, viennent alors ensuite quelques blocages mais qui je pense ne sont pas la cause mais l'effet de cet embouteillage soudain vraiment gênant. J'utilise le mot embouteillage vu que je ne trouve pas d'autres termes jusqu'à présent pour expliquer le problème, peut être un freeze? Durant la lenteur, même si j'annule les autovaccum, l'embouteillage ne se termine pas toujours.
Pour plus d'information nous utilisons également tomcat pour servir de serveur web applicatif, seulement là aussi je ne pense pas que le problème pourrait y venir.
Sauriez vous la cause de ce problème, car la situation devient assez gênante. Avez vous des solutions à proposer ?
Merci de votre attention à ce sujet
Je vous en remercie bcp pour vos réponses
Bonjour,
J'ai trouvé des messages du genre ci-dessous dans le log postgres :
LOG: process 31740 still waiting for AccessExclusiveLock on object 0 of class 1262 of database 0 after 1000.062 ms
DETAIL: Process holding the lock: 8655. Wait queue: 31688, 31740, 31359
Mais je ne les comprends pas vraiment est ce que vous pouvez me les expliquer svp, çà serait super de votre part
Par ailleurs, pour confirmation, les log genre LOG: disconnection: session time: 0:01:00.373 voudraient elles dire qu'une session a été déconnectées , mais est ce du fait de la deconnexion de l'utiliateur , ou le processus a été contraint d'être déconnecté ??
Bonne soirée à vous, et merci d'avance de l'attention que vous pouvez apporter à ce sujet ^_^
Ok, merci pour ces liens.
Et merci pour vos réponses.
Vous ne pourrez pas promouvoir le s1 simplement en renommant le recovery.conf en recovery.done.
Ca ne marche pas comme ça.
Il faut utiliser le trigger_file et laisser faire postgresql.
>>> Mais si j'utilise le trigger_file et laisser à postgresql de gérer çà, est ce que postgresql ne va t'il pas basculer le slave S1 en master, mais aussi le master M1 en slave ? Situation que je n'aimerai pas avoir, j'aimerai seulement isoler le master M1 pour une maintenance et ne pas arrêter la production.
J'ai vu de la réindexation, mais c'est une écriture et cela ne se fait que sur le maître (et est du coup répliqué sur l'esclave). Du coup, en dehors de la réindexation, quel autre maintenance voulez-vous faire ?
>>> Exact, mais en bref ce que je désire exactement c'est de ne faire la maintenance, la réindexation donc , que sur le serveur M1 vu que la réindexation verroux l'accès à la table, je voudrais donc basculer la production vers S1 pendant qu'on execute un réindexation sur M1. Ce cas aiderait bien lors d'une réparation de base corrompue par exemple. Mais puisque comme vous le dite
Si la "corruption" est "logique", càd qu'il vient d'un bug applicatif, oui, elle sera répliquée sur le standby.
, bah dans ce cas on devrait aussi donc réparer la réplique. Et qui est dommage, annulera donc la demande que j'aimerai faire.
Petite curiosité toute de même, n'existe donc t il pas un moyen de se protéger contre la corruption vu que celui ci prend beaucoup de temps pour la réparation surtout dans de cas de grosse lignes d'enregistrements ?
Pour basculer simplement le master en slave et vice versa vous pouvez toujours implémenter PAF (PostgreSQL Automotic Failover)
>>> Existe t il un moyen autre plus simple , ou pouvez vous me filer un lien de documentation, genre manuel pour implémenter ce PAF ?
Merci à vous
Donc, il n'est pas possible d'avoir une réplication master/master avec postgresql-9.4 ?
Sinon j'ai pensé pour le sénario1 :
>>> Objectif : Isoler M1 en maintenance et lancer la produciton sur S1.
=> Step1: on paramètre S1 de façon à pouvoir basculer en mode master, ie:
- Arrêter S1
- Renommer postgresql.conf S1 en postgresql_S1_slave.conf
- Copier postgresql.conf M1 et le coller dans le repertoire data de S1 avec les bon droits notemment pour l'user postgres, veuillez à bien vérifier le répertoire de archive_command, la source étant S1 maintenant
- Renommer recovery.conf en recovery.done pour désactiver recovery.conf de S1 temporairement
- Démarrer S1, qui normalement maintenant devra pouvoir accepter les transactions de lectures/écritures
- Pointer les connexions d'applications vers S1
=> Step2: isoler M1 pour une phase de maintenance
- Sauvegarder postgresql.conf de M1 dans un emplacement temporaire
- Désactiver archive_command dans postgresql.conf de M1 puisque S1 prend la main actuellement
- Si la maintenace n'a pas encore débuter, commencer la maintenance de M1
>>> En ce moment, on devrait pouvoir travailler sur S1 et isoler M1 en phase de maintenance
Scénario2:
>>> Objectif : la phase de maintenance de M1 étant fini on voudrait maintenant rattraper le retard de M1 et puis basculer la production vers M1, S1 sera de nouveau Slave.
=> Step3: on va faire une sauvegarde à chaud de S1
- Arrêter M1 après avoir vérifier que la maintenance a réussi
- Lancer pg_start_backup('label');
- Utiliser rsync pour copier le repertoire data de S1 vers le repertoire data de M1 (normalement rsync ne va copier que les data modifié durant le retard ce qui va diminuer largement le temps de copie)
- Lancer de suite pg_stop_backup(); après avoir fini la copie avec rsync
=> Step4 : rattraper le retard de M1 et le lancer en tant que slave
- Copier postgresql_S1_slave.conf avec les bon droit notemment l'utilisateur postgres et coller dans le repertoire data de M1 en tant que postgresql.conf
- Paramétrer recovery.conf de M1
- Paramétrer et reloader pg_hba.conf de S1 afin qu'il accepte la connexion de M1
- Démarrer M1 qui va entrer en mode récupération pour rattraper son retard
=> Step5 : Une fois M1 démarrer et synchroniser avec S1, basculer M1 en mode master et faire S1 en mode slave
- M1 et S1 étant synchroniser (vérifier par select * from pg_last_xact_replay_timestamp(); sur M1), arrêter les deux serveurs.
- Sur M1: reprendre le fichier de configuration de M1 sauvegardé dans Step2. renommer recovery.conf en recovery.done. Démarrer M1 et repointer les connexions d'applications vers celui-ci. M1 est maintenant master
- Sur S1 : refaire Step4 mais cette fois ci en remplaçant M1 par S1 et en oubliant le paramétrage de pg_hba.conf qui devrait déjà être prise en compte dans M1. S1 sera de nouveau slave après son redémarrage
***** Qu'en pensez vous, est ce que ce concept pourrait marcher ? Ou avez vous des idées/méthodes meilleures ???
***** Donc, si je comprends bien et pour confirmation, si la base master est corrompue (par ex au niveau d'une ligne de pg_toast), la réplique slave elle aussi sera corrompue ???
Merci de votre attention sur ce sujet
Bonjour,
J'aimerai avoir une haute disponibilité sur une base de données présente dans deux serveurs linux M1 et S1 avec postgresql9.4 installés. M1 en mode master et S1 en mode slave qui sert de réplication.
- 1er scénario >>>>, j'aimerai que lors de phase de maintenance obligatoire du master M1 (par exemple une réindexation de la base,...), on bascule les deux serveurs. C'est à dire le slave S1 devient master et le master M1 sera en maintenance durant ce temps.
Question scénario 1, déjà comment on s'y manipule exactement, pouvez vous m'indiquez les étapes à suivre pour bien basculer le slave S1 en master sachant que M1 ne doit pas être arrêté mais seulement isolé pour une maintenance?
- 2ème scénario >>>>, Une fois la maintenance de la base M1 effectuée. Il serait maintenant temps de rebasculer les deux serveurs pour atteindre leur role initial, ie M1 redevient master et S1 redevient slave.
Question scénario 2, là aussi comment on s'y prend exactement pour ne pas perdre les données et de rebasculer S1 en slave et M1 en master ?
*** Question spéciale : a) si la base master M1 est corrompue et devra donc entrer en phase de maintenance, est ce que dans ce cas le slave S1 sera elle aussi corrompue ??? b) si on a déjà entamé la phase de maintenance du master M1 sans basculer S1 en master ex: reindexation + vaccum analyze de M1, est ce que dans ce cas S1 sera aussi en phase de maintenance, ie les reindex et vaccum analyze faites sur le master sont elles aussi impactées dans le slave ?
J'espère que vous pouvez m'éclaircir sur ces points dont je ne vois pas trop d'exemple de cas détaillé dans la doc postgresql. Alors qu'il me semble vraiment important de bien connaitre les manipulations pour ces genres de cas.
Merci d'avance de vos réponses
Bonjour,
Merci pour cette solution, en effet celle - ci à résolu le problème.
Bonjour,
Nous disposons d'un système de réplication master/slave sur un environnement linux avec postgreSQL-9.4.
Nous voulons utiliser la base slave en tant que serveur de reporting. Il existe donc des requêtes SQL assez couteuses (ex durée d’exécution dans les 15mn) qui devraient être lancées sur ce slave. Cependant lorsqu'on lance ces requêtes longues, on obtient l'erreur suivant:
ERROR: canceling statement due to conflict with recovery
DETAIL: User query might have needed to see row versions that must be removed.
Nous avions déjà paramétré les deux paramètres "max_standby_archive_delay" et "max_standby_streaming_delay" à 1800 secondes afin de laisser plus de temps au slave à exécuter la requête, pourtant l'erreur subsiste toujours.
Est ce que vous pouvez expliquer à quoi est due ce message d'erreur exactement, et comment la résoudre ?
Merci d'avance.
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.
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.
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]
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.
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
