Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#101 Re : Réplication » REPLICATION : création système de basculement haute disponibilité » 31/05/2017 16:45:20
Ok, merci pour ces liens.
Et merci pour vos réponses.
#102 Re : Réplication » REPLICATION : création système de basculement haute disponibilité » 31/05/2017 16:15:21
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 
#103 Re : Réplication » REPLICATION : création système de basculement haute disponibilité » 31/05/2017 11:27:26
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
#104 Réplication » REPLICATION : création système de basculement haute disponibilité » 31/05/2017 09:15:38
- duple
- Réponses : 9
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
#105 Re : Réplication » REQUETE SUR SLAVE : ERROR: canceling statement due to conflict » 31/05/2017 08:48:39
Bonjour,
Merci pour cette solution, en effet celle - ci à résolu le problème.
#106 Réplication » REQUETE SUR SLAVE : ERROR: canceling statement due to conflict » 22/05/2017 10:11:10
- duple
- Réponses : 2
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.
#107 Re : Général » Base postgresql inaccessible » 13/05/2017 09:21:49
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.
#108 Re : Général » Base postgresql inaccessible » 26/04/2017 07:47:25
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.
#109 Re : Général » Base postgresql inaccessible » 25/04/2017 17:39:45
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]
#110 Re : Général » Base postgresql inaccessible » 24/04/2017 14:51:12
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.
#111 Général » Base postgresql inaccessible » 24/04/2017 10:47:34
- duple
- Réponses : 10
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
#112 Re : Réplication » pg_basebackup >>> unrecognized configuration parameter replication » 16/03/2017 17:41:47
Effectivement, il y a une version Postgresql 9.3 également installée sur l'hôte. Vous aviez raison c'est cette version qu'utilise pg_basebackup, avec le commande que vous aviez fourni cela retourne bien:
pg_basebackup --version
pg_basebackup (PostgreSQL) 9.3.3
Sinon, oui je parviens maintenant à accéder au lien que vous aviez fourni: http://docs.postgresql.fr/8.4/continuous-archiving.html. La je tente une sauvegarde et récupération de bas niveau. Espérons que tout va bien se passer.
Merci pour vos réponses et votre aide.
#113 Re : Réplication » pg_basebackup >>> unrecognized configuration parameter replication » 16/03/2017 10:12:11
Bonjour,
Merci de votre réponse rapide.
L'url suivant: http://docs.postgresql.fr/8.4/continuou … ving.html n'est pas disponible et renvoie une erreur de type 404. Ou c'est la doc 8.4 qui n'existe plus aussi 
Je vais quand même tenter de voir d'autre document si possible.
Mais c'est quand même bizarre que la commande pg_basebackup est reconnu par postgresql 8.4 (si je fais un pg_basebackup --help sur ligne de commande çà renvoie bien l'aide sur la commande), alors qu'elle n'est même pas foncitonnelle, non ?
En tout cas merci de votre aide.
#114 Réplication » pg_basebackup >>> unrecognized configuration parameter replication » 15/03/2017 18:20:41
- duple
- Réponses : 6
Bonjour,
Je travaille actuellement sur PostgreSQL 8.4 version Windows. Oui, la version est assez antérieure mais c'est l'existant actuel. Une migration vers linux + un upgrade de la version est prévue mais c'est pas mon sujet actuel.
Mon problème:
J'aimerai faire un pg_basebackup en vue de faire une sauvegarde niveau système.
Pour cela j'utilise la ligne de commande suivante: C:\Program Files (x86)\PostgreSQL\8.4>pg_basebackup -D Z:\sauve\pg_basebackup -Fp -R -X s -h localhost -p 5432 -U postgres
Mais cela me retourne un message d'erreur qui empêche l'execution.
Erreur: pg_basebackup : n'a pas pu se connecter au serveur : FATAL: unrecognized configuration parameter "replication"
Dans postgresql.conf il y a pas de trace de configuration pour une replication voir wall_level, wall_sender, ... surement que la version 8.4 n'était pas encore prévue pour cela. Cependant j'ai déjà activé l'archive commande qui marche après vérification. Par ailleurs, si je tente de créer un role ayant comme option REPLICATION, c'est pas aussi possible l'option REPLICATION n'est pas surement encore prise en compte aussi dans cette version 8.4.
Là du coup, je ne sais pas trop comment y remédier au problème, avez vous une solution ? De quoi pourrait bien venir ce message d'erreur?
Merci d'avance pour votre attention et des clartés que vous pouvez apporter aux explications