Vous n'êtes pas identifié(e).
- Contributions : Récentes | Sans réponse
#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
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
Guillaume.
Hors ligne