Vous n'êtes pas identifié(e).
merci Rjuju pour la réponse je vais chercher ça, pour slony on avait développé notre propre solution.
La réplication logique correspond à notre besoin tout simplement et pas la physique.
Mais ça répond pas du tout à ma question 
Bonjour,
j'ai une question qui me turlupine, j'ai mis en place 2 nouveaux serveurs (15 ) qui pour la première fois seront répliqués par la réplication native logique de PG ( pas de slony ici ).
On doit se faire à pas mal de changements mais c'est pas grand chose, ma question réside plutot de savoir comment les autres boites gèrent le fait d'avoir plusieurs base à modifier utilisées par plusieurs devs ?
Par exemple écrire une fonction c'est forcément l'envoyer à 2 endroits, on est donc pas à l'abris d'un oubli !
Existe il une façon de faire via par pgadmin ou autre pour envoyer des commandes simultanément à plusieurs endroit ?
Merci.
Bonjour,
Effectivement ça fonctionne parfaitement avec les 2 schémas de cette façon 
Malheureusement tout n'est pas rose j'ai complètement zappé que je changeais le numéro du node ( pour mieux organiser ) donc là le node reste node 3 alors qu'il devrait s'appeler node 7...
Soit je reste comme ça et tant pis mais à terme j'ai peur de m'y perdre ou alors je fais ma première hypothèse de chainer la répli pour ensuite supprimer le node non nécessaire...
Merci en tout cas.
Merci guillaume, je test ça demain je n'avais jamais pensé mettre plusieurs schemas dans mon pg_dump...
Pour la question un schema replique vers un schema, c'est toujours du 1 pour 1 donc ça devrait le faire.
Merci.
SI vous suavegardez un schéma particulier, il est normal que vous n'ayez pas le schéma slony. Quand vous faites un "pg_dump -n schema", seul schema est sauvegardé, c'est normal. Maintenant, je ne sais pas si c'est ce que vous avez fait vu que vous n'avez pas indiqué les commandes que vous avez saisies, mais ça y ressemble beaucoup.
Bonjour,
alors je fais pas de -n mais pas loin : pg_dump -h 127.0.0.1 --schema=monschema
Y a une autre façon de faire sans pour autant prendre tous les autres schemas se trouvant sur la machine ? ou au moins ne pas tous les remettre ( tous les prendre n'est en soit pas un soucis )
merci
Quand je dump et restaure le schema quand il remet les triggers de table ne trouvant pas le catalogue de slony dédié a la repli il ne les remet pas...
Je vais retenter lundi pour voir si je me trompe.
Bonjour,
Il m'arrive un truc assez incroyable ( aucun DATA center m'avait fait ça mais online/scaleway à décidé de me couper 2 de mes serveurs ( prétendu trop vieux lol ) sur lesquels j'ai 40 réplications slony... 300go de données chacun et pas que... )
Les serveurs arrêtés sont des répliquas pour faire simple.
J'ai très peu de temps donc j'essaye de trouver une autre solution que celle que j'avais en tete à savoir : repli A -> B je rajoute un serveur C pour avoir repli A -> B -> C et suppression de B ensuite pour avoir A -> C
Je trouve ça trop long même si c'est parfaitement viable.
J'ai donc pensé faire un dump de mon schema ( en ayant au préalable stoppé les daemons slon ) mais il perd les triggers en autre car à la restauration il ne retrouve pas le catalogue de la répli...
Y a t il une technique pour dumper le schema et le catalogue de la repli en question pour pouvoir remettre le tout sur le nouveau serveur ?
Merci de votre aide.
Alors j'ai a priori réussi a faire la réplication cascadé, j'ai du rajouter en path le lien de A vers C quand même, ça a permis de commencer là répli au final.
Par contre j'ai déplacé le slon du SERVER A sur le SERVER B j'ai pas testé si c'est obligatoire ou pas encore.
Au final le server A n'a plus de slon lié a cette répli et le server B en a 2 et biensur le serveur C à le sien.
ah oui et pour info même si concrètement ça n'a pas de rapport pour abaisser la charge serveur, j'ai modifié la fonction de création des listen qui était beaucoup trop abusé dans mon cas pour que ça ne génère que les nécessaires ( c'est bien pour quelques serveurs que tout le monde se parle mais pas quand on en met quasi 50 sur une seule répli )
JE vois pas ce que tu me demandes
En fait je me demande si c'est pas parce que j'enleve dans les path le server A et je ne laisse que le server B avec le C
store path (server = 3, client = 101, conninfo='dbname=RPP2 host=X.X.X.X port=5632 user=slony password=ght3kf');
store path (server = 101, client = 3, conninfo='dbname=RPP2 host=Y.Y.Y.Y port=5632 user=slony password=ght3kf');
ET au final je me demande si c'est pas le server A qui doit quand même initier la répli.
Je vais tenter de mettre le server A et de mettre le slon du A sur le B pour voir si ça passe...
en fait j'ai rien...
Sur server B
2021-06-01 15:12:06 CEST INFO remoteWorkerThread_2: SYNC 5002041762 done in 0.004 seconds
2021-06-01 15:12:06 CEST INFO remoteWorkerThread_165: SYNC 5000378823 done in 0.057 seconds
2021-06-01 15:12:06 CEST INFO remoteWorkerThread_122: SYNC 5000663252 done in 0.067 seconds
2021-06-01 15:12:06 CEST INFO remoteWorkerThread_173: SYNC 5000482111 done in 0.052 seconds
2021-06-01 15:12:07 CEST INFO remoteWorkerThread_116: SYNC 5003574780 done in 0.140 seconds
2021-06-01 15:12:08 CEST INFO remoteWorkerThread_160: SYNC 5003592020 done in 0.184 seconds
2021-06-01 15:12:08 CEST INFO remoteWorkerThread_121: SYNC 5003599409 done in 0.112 seconds
2021-06-01 15:12:08 CEST INFO remoteWorkerThread_118: SYNC 5000449529 done in 0.219 seconds
2021-06-01 15:12:09 CEST INFO remoteWorkerThread_141: SYNC 5000723217 done in 0.717 seconds
2021-06-01 15:12:09 CEST INFO remoteWorkerThread_165: SYNC 5000378824 done in 0.055 seconds
2021-06-01 15:12:11 CEST INFO remoteWorkerThread_160: SYNC 5003592021 done in 0.222 seconds
2021-06-01 15:12:14 CEST INFO remoteWorkerThread_189: SYNC 5001351640 done in 0.059 seconds
2021-06-01 15:12:18 CEST INFO remoteWorkerThread_194: SYNC 5001207575 done in 0.052 seconds
2021-06-01 15:12:23 CEST INFO remoteWorkerThread_4: SYNC 5000532991 done in 0.004 seconds
j'ai que des SYNC de tous les autres mais pas du nouveau qui est censé etre le 101.
Server C
2021-06-01 15:37:14 CEST INFO remoteWorkerThread_3: SYNC 5000775281 done in 0.024 seconds
2021-06-01 15:38:04 CEST INFO remoteWorkerThread_3: SYNC 5000775282 done in 0.025 seconds
2021-06-01 15:38:54 CEST INFO remoteWorkerThread_3: SYNC 5000775283 done in 0.024 seconds
2021-06-01 15:40:34 CEST INFO remoteWorkerThread_3: SYNC 5000775284 done in 0.025 seconds
2021-06-01 15:40:46 CEST INFO remoteWorkerThread_3: SYNC 5000775285 done in 0.023 seconds
2021-06-01 15:42:26 CEST INFO remoteWorkerThread_3: SYNC 5000775286 done in 0.024 seconds
2021-06-01 15:42:50 CEST INFO remoteWorkerThread_3: SYNC 5000775287 done in 0.025 seconds
2021-06-01 15:44:31 CEST INFO remoteWorkerThread_3: SYNC 5000775288 done in 0.025 seconds
2021-06-01 15:44:43 CEST INFO remoteWorkerThread_3: SYNC 5000775289 done in 0.025 seconds
2021-06-01 15:46:23 CEST INFO remoteWorkerThread_3: SYNC 5000775290 done in 0.025 seconds
pareil...
tu parles des logs des slons ? du server B et C ?
Pour revenir sur mon soucis, j'ai laissé tombé les replicas trigger ça ne fonctionne pas.
Je tente comme conseillé la réplication en cascade, mais pour l'instant ça en fonctionne pas, pour je ne sais quelle raison le sl_subscribe de mon server C est bien rempli mais il manque sa propre ligne, donc il ne sais pas qu'il est souscrit a un serveur, résultat pas de table dans sl_table.
Pourtant le add node fonctionne bien a partir de mon serveur B
Quelqu'un fait pas son job mais je sais pas qui.
Oui mais j'ai pas d'autres solutions, de toute façon pour le moment rien ne fonctionne.
Je dois trouver un moyen d'envoyer mes données de A vers C alors que A ne peux pas dialoguer avec C... le fait de passer par un serveur tampon était vraiment le meilleur choix.
D'ailleurs pour info on est en train de chercher du coté des états des triggers, on devrait avoir un bon résultat en modifiant le trigger de log en le passant ENABLE REPLICA TRIGGER ou ENABLE ALWAYS TRIGGER mais pour le moment rien n'y fait.
avec slony 2.2 il a rajouté 2 trigger en plus avec truncate donc on est passé de 2 à 4 juste pour ça.
Si j'utilise pas la cascade c'est pour 2 problèmes, d'une part la réplication est surchargé ( 1 master pour 40 slaves ) et les nouveaux serveurs qui viennent se rajouter ne sont pas joignable par le master mais uniquement quelques slaves.
donc au final découper la réplication c'était le meilleur plan.
Bonjour Guillaume !
c'est vraiment des réplications différentes, je me réexplique mieux :
SERVEUR A table toto réplique sur SERVEUR B la table toto ( j'ai donc la réplication _repli_test )
SERVEUR B table toto réplique sur SERVEUR C la table toto ( j'ai donc la réplication _repli_test2 )
donc sur le SERVEUR A j'ai bien les 4 triggers habituels mais sur le SERVEUR B je me retrouve avec 8 triggers
En gros j'ai l'impression que la fonction trigger qui est censé remarqué les update/insert/delete ne voit pas du tout ce qu'il se passe.
Si je désactive le trigger deny sur mon SERVEUR B et que je modifie la donnée à la main à ce moment là l'update se fait sur le SERVEUR C
Pour info j'ai mis les logs max sur slony mais il se passe rien, il fait des sync mais ça s'arrete la.
Bonjour,
Je sais que slony n'est plus vraiment utilisé, mais je tente ma chance avec ma question.
J'ai en place depuis longtemps une réplication de 1 vers n depuis longtemps, hors désormais mes nouveaux serveurs ne sont plus joignable par le master.
Donc basiquement j'ai créé une seconde réplication qui fait exactement la même chose d'un slave vers un autre ( slave qui lui peut parler aux autres ).
Donc concrètement j'ai 8 triggers sur ma table.
L'init s'est bien passé toutes mes données se sont bien retrouvées de l'autre coté, malheureusement les modifs sur les tables ne sont pas propagées.
Mon sl_log_1 ou 2 reste vide, les triggers ne remarquent pas du tout les modifications.
Est ce que quelqu'un a été confronté au problème ou pas ? si oui y a t il une solution, merci.
slony 2.2 / pg9.3
Ok je vais voir ce que je peux faire alors, merci.
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.
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.
J'avais jamais pensé faire ça pour une migration...
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.
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
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 
