PostgreSQL La base de donnees la plus sophistiquee au monde.

Forums PostgreSQL.fr

Le forum officiel de la communauté francophone de PostgreSQL

Vous n'êtes pas identifié(e).

#1 14/02/2020 11:36:28

pitpoule
Membre

Slony en 2020

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

#2 14/02/2020 15:20:38

rjuju
Administrateur

Re : Slony en 2020

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.

Hors ligne

#3 14/02/2020 15:34:22

pitpoule
Membre

Re : Slony en 2020

rjuju a écrit :

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 smile

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

#4 14/02/2020 15:57:40

rjuju
Administrateur

Re : Slony en 2020

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.

Hors ligne

#5 14/02/2020 19:04:45

ioguix
Administrateur

Re : Slony en 2020

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 smile

C'est moins complet, mais beaucoup plus simple.

++


Jehan-Guillaume (ioguix) de Rorthais
www.postgresql.org | www.postgresql.fr
www.dalibo.org | www.dalibo.com

Hors ligne

#6 16/02/2020 09:35:39

gleu
Administrateur

Re : Slony en 2020

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

#7 20/02/2020 15:51:06

pitpoule
Membre

Re : Slony en 2020

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

#8 26/03/2020 11:39:06

kenrio
Membre

Re : Slony en 2020

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 yikes

Hors ligne

#9 27/03/2020 13:10:37

pitpoule
Membre

Re : Slony en 2020

kenrio a écrit :

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 yikes

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

#10 30/03/2020 10:31:32

gleu
Administrateur

Re : Slony en 2020

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

#11 Hier 13:40:47

kenrio
Membre

Re : Slony en 2020

J'avais jamais pensé faire ça pour une migration...

Hors ligne

Pied de page des forums