Discussion :

[jlarribe]

Bonjour, voici ma problématique

Environnement : SQL server 2005

Problématique :
Nous disposons de plusieurs points géographiques (des points géographiques dits « distants » et un point géographique dit « central ») avec sur chacun une machine avec SQL server.
Chaque serveur possède la même table « Utilisateurs » avec deux champs : la clé primaire « NumClient » et un champ « email ».

Nous souhaiterions pouvoir faire des ajouts d’utilisateurs depuis chaque point géographique, que l’information soit envoyée au serveur central et qu’ensuite ce dernier redistribue les informations aux autres points géographiques.

Problème : si deux point géographiques ajoutent le même NumClient, comment se passe la résolution de conflits sur le serveur central ?

Nous avons exploré pour l’instant deux pistes :
- La première en utilisant le service broker pour l’envoi et le traitement des demandes des serveurs distants vers le central (broker logue les demandes en local, les envoie sur le serveur central où l'insertion est effectuée) ; puis une réplication transactionnelle pour renvoyer les informations aux serveurs distants.
o Intérêts :
nous loguons les demandes distantes et si il y a une coupure entre le serveur distant et le serveur central, les demandes peuvent être « rejouées » par la suite
il n’y a pas de problème d’ajout simultané du même NumClient puisque Broker traite tout sous forme de file.
o Inconvénients :
l’information n’est pas immédiatement exploitable sur le serveur distant, nous sommes dépendant du temps de réplication et donc il est impossible de « prédire » le moment ou l’information sera disponible.
l’état de file d’attente peut créer un goulot si beaucoup de demandes arrivent en même temps et le temps de traitement sera encore allongé.

- La seconde reprend le schéma précédent avec une système de réplication de fusion. Cette solution semble répondre en tout point à notre besoin cependant nous n’avons pas encore eu le temps de la tester complètement ; mes questions sont surtout liées à ma structure de données Utilisateurs (NumClient (PK), Email). Je me demande si le problème ne vient pas de la table elle-même et s’il ne faudrait pas rajouter un champ dans la table du style « IdPointGeo » pour avoir une unicité du couple NumClient / PointGeo et non du champ NumClient seul ; ainsi chaque point géo pourrait faire ses ajouts d’utilisateurs sans générer de problèmes d’intégrité au moment d’arriver sur le serveur central.

Merci de vos réponses

[SQLpro]

Problème : si deux point géographiques ajoutent le même NumClient, comment se passe la résolution de conflits sur le serveur central ?

Ceci peut être résolu si vous êtes en auto incrément en spécifiant la valeur de départ et le pas.
Par exemple avec 5 serveurs il suffit de décider que les auto incréments se feront de la sorte :
IDENTITI(1, 5) => sur le serveur 1
IDENTITI(2, 5) => sur le serveur 2
IDENTITI(3, 5) => sur le serveur 3
IDENTITI(4, 5) => sur le serveur 4
IDENTITI(5, 5) => sur le serveur 5
etc...

Ensuite, si les données des serveurs autre que son propre lieu ne peuvent être modifiées, alors prenez une réplication transactionnelle ou peer to peer plutôt que la fusion qui modifie profondément les tables et nécessite une grosse admin (gestion des conflits).

Dans tous les cas définissez un temps de latence d'au moins quelques minutes plutôt que "dès que possible" (instantanée).

La dernière solution pouvant être d'utiliser service broker pour distribuer les données. Avantages considérables : asynchrone, transcationné, fiable, sécurisé, crypté et over http !

A +

[jlarribe]

Merci pour cette réponse, l'idée de l'auto incrément est tout à fait intéressante, nous allons explorer cette piste.

Je reviens vers vous si jamais j'y vois certaines limites.

Si toutefois certains d'entre vous ont déjà mis en place ce type d'architecture, je serais curieux d'avoir aussi leur avis.

Merci