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

#1 18/12/2012 15:18:54

gosselin
Membre

[réplication asynchrone symétrique ] rubyrep - retour d'expérience

Dans le cadre d'un développement spécifique, nous recherchons une solution apte à réaliser de la réplication asynchrone symétrique (de type Maitre-Maitre) à la demande. Notre application est sous environement win32. il semble que rubyrep soit le seul produit à répondre à nos besoins.
L'utilisez-vous et si oui, y-a t-il des problèmes de fiabilité ou de lenteur ?
Y-a t-il d'autres solutions pour des applications Client-serveur avec des postes itinérants déconnectés qui doivent pouvoir lire et écrire dans la base et se synchroniser avec le siège ?
Par avance, merci.

Hors ligne

#2 18/12/2012 15:24:39

gleu
Administrateur

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

Bucardo me semble plus adapté à ce type de cas. Ce sera de toute façon lent. Toute solution maître/maître est intrinséquement lente.


Guillaume.

Hors ligne

#3 18/12/2012 15:35:49

gosselin
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

Bucardo ne tourne pas sous Win32 à ma connaissance. Il y a un script PERL qui utilise des spécificités Unix et qui n'a jamais été porté sous windows.

Hors ligne

#4 19/12/2012 13:34:26

kenrio
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

Ce genre de réplication est loin d'être évidente et sacrément complexe et dangereuse.
Envisagez une autre façon de travailler coté base n'est pas possible ? multi schéma ? certaines tables descendantes alors que d'autres montantes ?...

Hors ligne

#5 19/12/2012 15:27:01

gosselin
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

Le besoin est pourtant simple : une CRM avec des fiches clients qui peuvent être modifiées par le siège et par les postes déportés, mais qui fonctionnent en mode déconnecté. Au delà de ça, c'est plus de 50 tables concernées, mais je ne vois pas comment tourner les choses autrement.
Je viens de tester RubyRep, il répond aux spécifications. Maintenant, est-il stable  ?Pas évident, très peu de retour d'expérience à priori...

Hors ligne

#6 19/12/2012 15:34:37

kenrio
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

il se passe quoi quand le siege modifie la fiche d'un client et que le commercial sur son poste modifie la meme fiche client ?
C'est une vraie question qui me turlupine smile

Hors ligne

#7 19/12/2012 15:42:46

gosselin
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

Il y a une gestion des droits et celui qui a le plus de droit l'emporte, tout en générant un log de conflit pour retrouver ses petits. l'idéal serait de gérer à la colonne près, ce que nous envisageons mais qui est assez lourd à développer et pas forcément possible avec Rubyrep. Mais la première solution (par date de modif et par droit), si.

Hors ligne

#8 19/12/2012 15:48:50

kenrio
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

ah ok c'est votre crm qui gère les conflits.
Ne connaissant pas du tout rubyrep je ne vais pas pouvoir vous aidez, dommage.

Hors ligne

#9 19/12/2012 15:59:37

gosselin
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

En fait, c'est une procédure de gestion de conflit écrite en Ruby qui fonctionne avec le gestionnaire de conflit de rubyrep. Les droits et les dates de modifs sont dans la database (triggers pour les dates et droits).

Hors ligne

#10 19/12/2012 17:49:51

kenrio
Membre

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

ok merci du renseignement

Hors ligne

#11 20/12/2012 12:13:38

gleu
Administrateur

Re : [réplication asynchrone symétrique ] rubyrep - retour d'expérience

Ce n'est clairement pas un problème simple, ce qui est la raison pour laquelle les solutions style rubyrep et bucardo laissent le problème de gestion des conflits à l'utilisateur smile


Guillaume.

Hors ligne

Pied de page des forums