Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous.
J'ai eu récemment besoin de répliquer/synchroniser des données contenues dans une base maître d'un PC portable vers une base esclave sur un serveur. Bien sûr le PC portable n'est pas toujours connecté, le serveur doit toujours mettre à disposition les dernières données en sa possession et les deux n'ont pas de raison d'utiliser une même version de postgreql.
Il y de nombreux articles sur le net qui présentent les solutions de réplication :
http://www.postgresql.org/docs/current/ … tions.html
http://www.dalibo.org/hs44_une_synthese … s_le_futur
Mais, sauf erreur de ma part, aucune de ces solutions ne répond au besoin simplement. Ce serait faisable par un 'bon dimensionnement' du cache, cad des fichiers nécessaires à la réplication, et supposerait donc une gestion d'une limite des modifications possibles sur le portable avant un nécessaire transfert sur le serveur. Ai-je bien compris ? Y a-t-il une solution simple ?
Je me suis donc tourné vers des solutions de synchronisation et j'ai trouvé :
- pgdiff et apgdiff que j'ai rapidement éliminées car j'ai compris qu'elles reposent sur un dump complet de la base et je ne peux pas les considérer comme performante en terme de charge réseau
- dblink qui nécessite une programmation complète de ce que l'on souhaite
- easter-eggs.com/Systeme-de-synchronisation, qui semble être une bonne solution intermédiare tout en nécessitant que les tables à répliquer diposent d'un index entier
- pg_comparator qui fonctionne bien et répond parfaitement au besoin énnoncé au début de ce post
A noter que ces 3 solutions peuvent fonctionner avec des versions de postgresql différentes.
Hors ligne
Mais, sauf erreur de ma part, aucune de ces solutions ne répond au besoin simplement.
Je ne vois pas ce qui permet d'affirmer ça. À cause de la version différente, on ne peut pas utiliser la réplication de PostgreSQL. Mais Slony au moins est possible.
Ce serait faisable par un 'bon dimensionnement' du cache, cad des fichiers nécessaires à la réplication, et supposerait donc une gestion d'une limite des modifications possibles sur le portable avant un nécessaire transfert sur le serveur. Ai-je bien compris ?
Je ne sais pas pour vous mais, moi, je n'ai rien compris 
Y a-t-il une solution simple ?
Il vous faut une solution capable de fonctionner malgré des coupures de connexion, capable de lire les données des deux côtés, et que la version de PostgreSQL n'est pas forcément identique entre les deux. Slony est capable de tout ça.
Je me suis donc tourné vers des solutions de synchronisation et j'ai trouvé :
... des tas de trucs lents qu'on ne rencontre jamais en production. Avec un extra-terrestre dans le lot, à savoir dblink (en quoi il répond à votre besoin ?). Bref, pour moi, ce ne sont pas des solutions.
Guillaume.
Hors ligne
Ce serait faisable par un 'bon dimensionnement' du cache, cad des fichiers nécessaires à la réplication, et supposerait donc une gestion d'une limite des modifications possibles sur le portable avant un nécessaire transfert sur le serveur. Ai-je bien compris ?
Je ne sais pas pour vous mais, moi, je n'ai rien compris
Je dirais qu'il parlait de positionner le wal_keep_segments à une valeur suffisamment haute.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour gleu et rjuju,
merci pour votre réactivité
1) Slony :
Je n'ai pas pris le temps de le tester car j'ai lu, probablement trop rapidement, qu'il n'était plus en 'vogue'.
Bucardo est également capable de fonctionner avec des versions différentes, je l'ai testé, cela fonctionne bien lorsque les serveurs sont toujours actifs, je n'ai rien compris pour l'organisation simple d'une reprise suite à l'arrêt du maître ...
2)
Je dirais qu'il parlait de positionner le wal_keep_segments à une valeur suffisamment haute..
C'est effectivement ce que j'ai écris, désolé si j'ai utilisé un terme non technique que je souhaitais plus accessible à tous. Comment définir cette valeur suffisamment haute sans spécifier une limite de modifs dans le maître ? et corollairement comment suivre et ne pas dépasser cette limite dans le maître ?
Je suppose que Slony passe par une telle config ?
3) Aucun de vous deux ne s'exprime sur pg_comparator ?
Au plaisir de vous lire et
si un autre lecteur a un retour d'expérience entre cette solution et Slony ou Bucardo ce serait bien de la partager.
Hors ligne
1. Dommage de s'en fier à des on-dit.
2. Il n'y aura jamais de "bonnes valeurs". Peut être une "suffisamment bonne mais risquée quand même". Et là, c'est impossible pour nous de dire laquelle. Tout dépend du nombre de journaux consommés en une période de temps. Suivant votre débit en écriture, cela peut varier énormément. Quant à Slony, non, il n'a pas cette configuration là. La réplication interne de PostgreSQL n'a rien à voir avec la configuration de Slony.
3. Ah si, je me suis exprimé : "... des tas de trucs lents qu'on ne rencontre jamais en production. [...] Bref, pour moi, ce ne sont pas des solutions."
Quant à un retour d'expérience, oui, on a un client qui utilise Bucardo depuis quelques temps. Pas mal de soucis de conflits. Du coup, on aimerait beaucoup passer à quelque chose de fonctionnel, comme la réplication interne de PostgreSQL.
Guillaume.
Hors ligne
1) Il faut bien démarrer, si je m'étais fier à des on-dits je n'aurai pas écrit ce post.
2) et donc ? cela semble toujours rester une question sans réponse ... autre que pg_comparator ? qui fonctionne sans ce poser cette question !
3) une solution est toujours relative à un problème, je n'ai pas exprimé de contrainte de temps dans mon besoin !
Merci pour le retour sur Bucardo qui corrobore le mien.
A noter que j'ai également tester la réplication interne de Postgresql qui fonctionne bien mais nécessite des versions identiques et une 'bonne valeur' au point précédent
A l'occasion j'essairai Slony pour comprendre 2) et comparer sa rapidité avec pg_comparator qui reste donc aujourd'hui la solution à mon besoin.
Dernière modification par PmGs7 (01/03/2016 13:39:55)
Hors ligne
Concernant le wal_keep_segments, vous pouvez utiliser à la place un slot de réplication (depuis la version 9.4) qui retiendra le nombre minimum de WAL pour qu'un serveur secondaire déconnecté puisse continuer à se resynchroniser lorsqu'il se reconnecte. Bien évidemment, cela veut également dire que si ce serveur met trop de temps à revenir, les WAL pourront s'accumuler jusqu'à provoquer un arrêt de service sur le primaire.
Julien.
https://rjuju.github.io/
Hors ligne
Pages : 1
