Vous n'êtes pas identifié(e).
Pages : 1
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
Dernière modification par kenrio (25/05/2021 14:47:44)
Hors ligne
Il est toujours utilisé, notamment pour les mises à jour majeures 
La description du problème manque énormément d'informations. Néanmoins, de ce que j'en comprends, si ça concerne les mêmes tables en utilisant des sets différents, non, ça ne peut pas fonctionner. Les triggers sont activés sur le serveur primaire, et désactiver sur le secondaire. Donc ce secondaire ne peut pas servir pour envoyer ailleurs grâce aux triggers.
Guillaume.
Hors ligne
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.
Hors ligne
Oui, c'est bien ce que je disais. Quoique ça me paraît beaucoup, l'histoire des 4 triggers. A priori, une table a deux triggers, un pour logger les modifications, un pour empêcher les modifications. Suivant le contexte, un trigger sera activé et l'autre désactivé. En intégrant la table toto sur un deuxième set, il aura double dose de triggers (donc 4 normalement, 2 par set). Le trigger d'empêchement des modifications est activé et doit prendre le pas sur celui de log. C'est pourquoi, lorsque tu désactives le deny, l'UPDATE se fait bien. Mais clairement, Slony n'est pas prévu pour ça et je ne suis pas particulièrement étonné que le reste ne passe pas.
Pourquoi n'utilises-tu pas la vraie fonctionnalité de cascade de Slony ?
Guillaume.
Hors ligne
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.
Hors ligne
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.
Hors ligne
Ça me paraît très dangereux de jouer à ça. Vous n'aurez aucune garantie que le résultat est réellement fonctionnel.
Guillaume.
Hors ligne
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.
Dernière modification par kenrio (26/05/2021 10:04:47)
Hors ligne
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.
Hors ligne
Que disent les journaux applicatifs de Slony ? parce que la solution se trouve probablement là.
Guillaume.
Hors ligne
tu parles des logs des slons ? du server B et C ?
Hors ligne
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...
Hors ligne
En effet, c'est plutôt vide. Enfin, vide d'informations. Difficile d'aller plus loin sans avoir un cas complet à rejouer de son côté. Tu penses pouvoir préparer ça ?
Guillaume.
Hors ligne
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...
Dernière modification par kenrio (02/06/2021 10:20:33)
Hors ligne
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 )
Dernière modification par kenrio (03/06/2021 10:46:32)
Hors ligne
Pages : 1
