Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#1 Re : Général » Modification Checkpoint_segments ? » 31/03/2020 17:57:08
Ok je vais voir ce que je peux faire alors, merci.
#2 Re : Général » Modification Checkpoint_segments ? » 31/03/2020 16:43:02
Merci de répondre,
Non le log_checkpoints est a off.
En 1min pendant la mise a jour ( une partie vu qu'on découpe tout pour aider ) j'ai 7 wal de 16mo qui sont produit.
Passer log_checkpoints en on ça va pas rajouter une charge serveur alors que je cherche à la réduire ?
JE serais bien chaud a mettre temporairement 10 en segment et 0,9 en target.
#3 Général » Modification Checkpoint_segments ? » 31/03/2020 13:46:10
- kenrio
- Réponses : 4
On a une grosse mise à jour en cours qui fait énormément d'update,select,delete sur 3 tables environs ( plusieurs millions de lignes )
J'ai donc fatalement ça qui arrive :
2020-03-31 13:33:27 CEST [7687]: [93-1] user=,db=,remote= LOG: checkpoints are occurring too frequently (11 seconds apart)
2020-03-31 13:33:27 CEST [7687]: [94-1] user=,db=,remote= HINT: Consider increasing the configuration parameter "checkpoint_segments".
Ma question est plutot comment je dois modifier pour aider la mise à jour pour ensuite revenir à l'état initial ?
Par défaut sur mon pg9.3 j'ai laissé :
#checkpoint_segments = 3 # in logfile segments, min 1, 16MB each
#checkpoint_timeout = 5min # range 30s-1h
#checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0
Je modifie juste le segments ou aussi le target ?
De plus cela nécessite t il un restart de pg ?
Merci de votre aide.
#4 Re : Réplication » Slony en 2020 » 31/03/2020 13:40:47
J'avais jamais pensé faire ça pour une migration...
#5 Re : Réplication » Slony, comment réduire l'envoi ? » 26/03/2020 14:51:19
Ne trouvant pas, je donne ici "ma solution", comme c'était une transaction qui a créée ces 11 millions de lignes, slony n'était pas en mesure de "découper" l'envoi, j'ai donc supprimé les lignes dans sl_log 1 et 2 pour que la suite reprenne.
Me reste plus qu'a recréer la table en question avant que slony n'est une mise à jour à faire sur cette fameuse table.
#6 Réplication » Slony, comment réduire l'envoi ? » 26/03/2020 11:41:19
- kenrio
- Réponses : 1
Bonjour,
J'ai un soucis qui m'étais jamais arrivé c'est qu'un site à fait une grosse mise à jour, et maintenant slony a 7go a envoyer, hors leur ligne adsl est très mauvaise ( et en plus sur l'upload... ) donc ça mouline beaucoup trop.
Je trouve pas où je peux paramétrer slony pour lui dire d'envoyer par petit paquets, slony sait il faire ça ? si oui comment ?
Merci, si quelqu'un passe par là XD
#7 Re : Réplication » Slony en 2020 » 26/03/2020 11:39:06
Les triggers sont très léger, ils sont juste la pour bloquer l'écriture quand on est sur le répliqué.
Pourquoi prendre slony quand la répli native de PG12 fait le taf ?
Toutes mes réplications sont en slony mais j'aimerais passer à PG12 un jour 
#8 Re : Général » Crash bdd 9.3 » 05/07/2019 11:00:59
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...
#9 Général » Crash bdd 9.3 » 05/07/2019 10:23:26
- kenrio
- Réponses : 2
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.
#10 Réplication » Slony table sl_listen énorme ! » 16/07/2018 17:03:12
- kenrio
- Réponses : 0
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.
#11 Re : Général » Connexion perdu ? » 03/07/2018 15:43:40
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
#12 Général » Connexion perdu ? » 03/07/2018 15:19:45
- kenrio
- Réponses : 2
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.
#13 Re : Général » Stratégie d'archivage » 07/03/2018 12:05:37
Bonjour,
PG10 avec la réplication logique semble être le mieux quand même.
Slony ne peux pas faire ça.
#14 Re : Général » tuer un processus postgres » 21/02/2018 16:59:46
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... )
#15 Re : Général » tuer un processus postgres » 21/02/2018 15:54:04
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 ?
#16 Re : Général » tuer un processus postgres » 21/02/2018 13:18:29
avec une commande kill : kill -15 17315 ( par exemple )
bon directement depuis postgres c'est bien aussi
#17 Re : Général » Accompagnement migration vers PostgresSQL » 19/02/2018 16:29:50
C'est globalement une offre d'emploi mais pour des consultants.
Mais le sujet est intéressant ^^
#18 Re : Réplication » Replication logique ? » 13/11/2017 11:08:56
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.
#19 Re : Réplication » Replication logique ? » 10/11/2017 16:52:55
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.
#20 Re : Réplication » Replication logique ? » 06/11/2017 10:40:08
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 ^^
#21 Réplication » Replication logique ? » 03/11/2017 14:59:07
- kenrio
- Réponses : 6
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.
#22 Re : Réplication » Slony - réplication à la demande » 31/08/2016 15:40:57
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.
#23 Re : Réplication » Slony - réplication à la demande » 31/08/2016 15:19:31
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 ^^
#24 Re : Réplication » Slony - réplication à la demande » 31/08/2016 14:52:46
/HS coucou Gleu ça faisait longtemps 
#25 Re : Réplication » Slony - réplication à la demande » 31/08/2016 14:02:47
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.