Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
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
Hors ligne
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.
Julien.
https://rjuju.github.io/
Hors ligne
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é.
Hors ligne
Il s'agit clairement d'un outil complexe, qui nécessite beaucoup d'investissement côté prise en main avant de pouvoir sérieusement penser le mettre en production (notamment pour la gestion des DDL, mais aussi la supervision et tous les autres aspects). Personnellement, j'ai toujours essayé d'en rester le plus loin possible, mais d'autres personnes ici ont beaucoup d'expérience avec cet outil.
Julien.
https://rjuju.github.io/
Hors ligne
Salut,
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.
++
Hors ligne
Même avis que ioguix. Je ne l'utilise que pour les mises à jour majeures quand d'autres méthodes (de mise à jour) ne sont pas possibles.
Guillaume.
Hors ligne
Pour remettre un peu mon besoin dans son contexte, j'ai d'abord essayé de mettre en place pglogical pour "exporter" les tables. La mise en production a été problématique car notre BDD fait tourner des traitements qui génèrent des transactions longues impliquant des update massifs. On a rapidement été confronté à des saturations de fichiers WAL sur disque, lié au slot de réplication. On a du faire marche arrière. C'est pour cela que je suis parti sur slony.
Ce qui m'inquiète aussi, ce sont les performances car slony met en place des triggers, j'ai peur que cela ralentissent fortement les traitements d'update.
Hors ligne
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 
Hors ligne
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
Hors ligne
Oui, c'est ce que je fais aussi quand un passage pg_dump/pg_restore n'est pas possible. Slony est une bonne solution tant que la version à migrer ne dispose pas de la réplication native.
Guillaume.
Hors ligne
J'avais jamais pensé faire ça pour une migration...
Hors ligne
Pages : 1
