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
Car je veux répliquer des données de 9.6 -> 12
J'ai essayé aussi pglogical mais je fais face à des problèmes de saturations de fichiers wal sur disque, dû à notre activité: transactions longues + beaucoup DDL
Toutes mes réplications sont en slony mais j'aimerais passer à PG12 un jour
]]>Je l'utilise principalement pour les mises à jour majeure.
Dans les autres cas, je lui préfère la répli logique quand c'est possible...sauf que je n'ai pas eu d'autres cas depuis que la répli logique existe
C'est moins complet, mais beaucoup plus simple.
++
]]>Il y a au moins un changement lié à pg12: https://github.com/ssinger/slony1-engin … 5b7f4ebe0a
Peut-être ont-ils juste oublié de marquer cette version comme suportée ailleurs dans le code.
De ce que j'ai testé, ça fonctionne.... et plutôt bien même d'ailleurs
Le truc , c'est que je trouve cet outil complexe.... et je voudrais avoir un avis général dessus avant d'investir plus d'énergie et de temps. Je me posais aussi la question de sa viabilité.
]]>Peut-être ont-ils juste oublié de marquer cette version comme suportée ailleurs dans le code.
]]>Je suis en train d'étudier la mise en place de Slony pour externaliser un ensemble de tables d'un PG 9.6 vers un PG12. J'ai l'impression que le projet est à moitié vivant/mort. Sur le site, on voit que la dernière version est compatible avec PG 12 mais quand on fait l'install, on a un message indiquant que la 12 n'est pas supportée.
Est ce qu'il est pertinent d'utiliser encore cet outil pour de la prod sur des versions récentes de PG ? Est ce que certains d'entre vous l'ont mis en production récemment ?
Merci
]]>