Vous n'êtes pas identifié(e).
J'étais plus sur cet optique de toute façon, je me demande même si le raid matériel HP ne serait pas la cause en fait...
Bonjour,
J'ai un soucis que je n'arrive pas a diagnostiquer, je n'arrive donc pas a savoir si pg est le problème ou la conséquence.
Je constate que le serveur passe en lecture seul, donc pg ne fonctionne plus, j'arrive avec difficulté à me connecter et ensuite lancer un reboot.
Les logs ne montre rien, les logs s’arrête d'un coup sans annoncer le moindre soucis, je trouve rien sur les autres logs de centos de tangible en espérant chercher au bon endroit.
Néanmoins mon nagios a capté un recovery de pg avant le crash violent, se pourrait il que ce recover ait tout fait planter ? mais pourquoi un recover se lance tout seul ?
Pour information j'ai eu le cas 2 fois en 1 semaine, alors que d'habitude c'était une fois ou 2 par an, j'ai plusieurs serveurs identiques (ghost et même machines) qui ont le soucis ( aussi peu souvent ) et d'autres qui n'ont jamais eu ça.
Je suis en pg 9.3 sur un centos 5.7 ( il n'est pas envisageable de migrer vers du centos 7 à cause notamment de slony... )
Merci pour votre aide.
Bonjour,
J'ai un soucis qui me tracasse de plus ne plus.
J'ai une réplication qui tourne depuis très longtemps de master vers X slaves ( 1 master pour 18 répliqués )
Mon soucis vient de la table sl_listen qui à la place de contenir juste ce qu'il faut il créé toutes les combinaisons possibles.
Par exemple j'ai fais un test pour 1 master et 2 slaves et j'ai 4 lignes de trop qui servent a rien pour moi :
table SL_LISTEN
origin ; provider ; receiver
1;1;2
1;1;130
2;1;130
2;2;1
2;130;1
130;1;2
130;2;1
130;130;1
Voici après nettoyage ce quelle devrait être :
1;1;2
1;1;130
2;2;1
130;130;1
Le problème c'est qu'a chaque rajout/delete de tables/noeuds la table se ré-empli de nouveau et rebelote je dois refaire le nettoyage.
Ma question au final est : Est ce normal que tous les noeuds se parlent entre eux s'en cesse ?
Merci.
C'est quand même fou le serveur de lyon est sur fibre orange et l'autre dans le datacenter d'online 
Merci quand même Gleu
Bonjour,
Depuis cette nuit ma réplication ne fonctionne plus et lors du transfert (COPY) de sl_log ( table slony ) j'ai cette erreur qui survient : FATAL: connection to client lost ( les 2 serveurs sont sur wan paris-lyon )
ça ressemble à un problème réseau mais comment le prouver ? sachant que j'arrive sans peine à me connecter (en faisant par exemple un psql -l) depuis paris vers lyon et vice versa.
Merci de votre aide.
EDIT : et celle ci en plus sur les logs slony :
CEST ERROR remoteWorkerThread_116_116: error at end of COPY OUT: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Bonjour,
PG10 avec la réplication logique semble être le mieux quand même.
Slony ne peux pas faire ça.
Ok merci, j'aurais du aller voir mes logs après pour voir ( c'était sur un serveur de dev donc je m'en foutais... )
J'utilise tout le temps un kill -15 ( sigterm ) j'ai du une fois utilisé le sigkill j'ai pas constaté de redémarrage d'instance, tu veux dire quoi par la exactement ?
avec une commande kill : kill -15 17315 ( par exemple )
bon directement depuis postgres c'est bien aussi 
C'est globalement une offre d'emploi mais pour des consultants.
Mais le sujet est intéressant ^^
Oui oui j'ai vu qu'il y avait eu une nouvelle numérotation.
En tout cas mes premiers tests de répli sont très concluant, la mise en fonction est d'une simplicité déconcertante, bidouillé la répli quand on s'amuse à cloné les VMS n'est pas un soucis.
Et j'aime beaucoup le fait qu'il ait mis la possibilité de commencer une répli sur une table pleine avec le copy data en false.
J'utilisais que très peu les droits utilisateurs ça sera une bonne occasion car laisser "open" sans protection je vais pas tenir longtemps sans boulettes 
Une mise à jour ! c'est très bien je vais pouvoir tester la migration de mes VMS qui ont déjà une répli test en cours.
Merci Guillaume pour la réponse, je suis en train de faire pleins de tests pour voir les différences réelles entre slony et la réplication logique de pg10.
Je vais devoir revoir ma façon de faire des failovers, voir à protéger mes slaves vu qu'il n'y a plus de triggers pour "protéger" en écriture les tables.
Et voir comment migrer tous mes serveur de pg9.3 à pg10 pour passer avec la réplicaiton logique XD
Super projet en perspective ^^
Bonjour,
Je suis en train de tester pg10 et la nouvelle réplication logique pour remplacer slony.
J'aurais aimé savoir ce qu'il en était de la fiabilité de cette réplication ? et si il y avait une limite de slaves ?
Merci.
oui, ça peut se faire avec les logs fichiers mais bon les scripts a faire sont bien plus galère.
après rien que la vue status fera l'affaire à mon avis.
en codant un peu y a moyen de faire une verif que les derniers events ne sont que des SYNC de base et non des mises à jour, après on peut aussi vérifier que les logs sont vide, etc,... enfin y a pleins de techniques possible en fait ^^
/HS coucou Gleu ça faisait longtemps 
bah pendant l'arrêt le nombre d'event va monter des que vous allez redémarrer tous les events retomberont a 1 ou 2 quand ils aura terminé.
En fait c'est pas du tout brutal comme façon, perso je coupe mes slons très souvent ( tous les jours pour les backups ) et j'ai jamais eu de soucis.
pkoi pas stopper la repli tout simplement et la relancer quand c'est bon ?
je me suis fais avoir à a cause d'un modif sur slony qui a lancé une copy sur 17 tables et j'ai vu 10 coeurs à 100%.
d'où mon erreur, désolé de pas pouvoir t'aider ^^
non je me plante c'est que je lance plusieurs copy en meme temps de mon coté ^^
La commande COPY est multi thread par défaut non ?
refaites une discussion svp.
pour la petite histoire j'ai enfin trouvé l'erreur dans mon log message qui après le reboot disparaissait, par chance j'etais là au bon moment.
donc rien a voir avec postgresql ce qui me rassure un peu.
voici l'erreur pour info :
Jan 22 22:14:23 kernel: command: Test Unit Ready: 00 00 00 00 00 00 Jan 22 22:14:23 kernel: mpt2sas0: task abort: FAILED scmd(ffff8104d9a21500)
Jan 22 22:14:23 kernel: mpt2sas0: attempting target reset! scmd(ffff8104d9a21500)
Jan 22 22:14:23 kernel: sd 0:1:0:0:
j'ai plus qu'a trouver comment résoudre ce problème
je me suis beaucoup posé la question à propos de verrous.
je vais potasser la doc sur les verrous, je suis quasi sur que le matos n'y est pour rien.
