Discussion :

[gregm954]

Bonjour,

1-J'ai une application qui écrit des données dans une base sql sur un serveur.
2-L’application n'est pas toujours connecté au réseau , les données sont donc envoyées sur une base sql en local.
3-LA base local et sur le serveur sont identiques(tables, champs)

Ma grande question quelle réplication dois je choisir??
réplication par fusion bidirectionnelle ou transactionnel?

L’application interroge la base sql pour savoir si le client existe , si il existe elle crée une nouvelle visite pour le client , si le client n'est pas dans la base, l'appli crée un nouveau client dans la table client et crée une nouvelle visite dans la table visite..

J’étais partis sur la réplication par fusion bidirectionnelle avec récupération en pull mais après avoir lu quelques postes sur le forum, la réplication par fusion est déconseillée, manifestement pour les problèmes de conflits des données.. très dur à gérer
Merci de votre aide et de vos conseils .
Greg

[SQLpro]

est-ce que les données doivent être simultanément présentes des deux côtés ?

Si oui, seule la réplication de fusion est possible. Toutes vos tables sans exception doivent avoir une clef primaire.

A +

[gregm954]

Je dirais pas forcément.., en gros j'ai un client toto inscrit dans la base serveur avec 2 visites d’inscrites , le client toto revient pour une troisième visite mais pas de réseau donc le logiciel inscrit le client toto dans la base local, puis créer une visite dans la table visite (visite1).
Une fois le réseau retrouvé dans la base serveur je dois me retrouver avec mon client toto et visite 1, Visite 2 et visite 3 inscrit dans la table visite.

Oui bien-sur toutes les tables ont une clé primaire.

Merci encore pour votre réponse..

[Michel.Priori]

L’application n'est pas toujours connecté au réseau
Ma grande question quelle réplication dois je choisir??
réplication par fusion bidirectionnelle ou transactionnel?

Lorsque la connectivité réseau n'est pas "fiable" la seule réponse est "fusion".
Une réplication transactionnelle n'a pas de mécanisme de résolution de conflit.

Imaginons
*2 serveurs : 1 au siège, 1 sur site
*un client TITI.
Le client a pris rdv la semaine dernière pour ce matin 10h.
Ce matin 8h pas de réseau et un coup de tel de Mme pour annuler le rdv, annulation (delete du rdv) faite par le siège
Ce matin 10h -toujours pas de réseau- le client se pointe sur site en disant qu'il a pu quand même se libérer => Prise en compte du rdv (update du rdv et insert dans des tables filles)
Le réseau est enfin rétabli vers 11h.
Que faire avec les informations de TITI ?

Ceci est un caricature de ce qu'on appelle un conflit de réplication.
Si la base n'était pas "répartie en multi-maitre" cette situation n'aurait jamais eu lieu.

Tout ça a un coût !
Ajout d'une colonne uniqueidentifier pour chaque table répliquée.
Les volumes en attente engorgent les serveurs.
L’optimisation des requêtes est plus compliquée.
L'administration au quotidien nécessite, au moins, une personne qualifiée.

De nos jours, avec internet omniprésent, il est rare d'avoir ce cahier des charges.
On préfère être dépendant du réseau, à l'image des solutions Cloud.
A vous de voir.

Si vous envisagez d'être en réplication de fusion LE conseil est de faire que la colonne uniqueidentifier soit la PK mais pas l'index cluster.
les tables qui ne disposent pas d'index cluster sont moins performantes.
Choisissez bien le votre.

[SQLpro]

Dans ce cas la réplication transactionnelle est possible en considérant que les postes clients alimente le serveur central.

Je ne voit pas du tout l'intérêt d'une réplication de fusion, très complexe, qui n'est utile que si les différentes sites peuvent mettre à jour la même information.

A +

[gregm954]

Bonjour,
Merci de vos réponses.

SQL pro, Oui..les postes clients ne font qu'alimenter le serveur central, en aucun cas ils modifient les données existantes.
Les postes clients lancent une simple requête sur la table client pour savoir si le client est déjà venu et donc savoir si le "logiciel" doit créer un nouveau client avec la première visite ou tous simplement si le client existe déja créer la visite suivante en inscrivant le numéro unique du client dans la table visite.

Bon bas j'ai créé , une VM Windows server avec sql server 2017 et un poste client, je vais mettre en place la réplication transactionnelle et faire des tests.... Je ferais peut être des tests avec la réplications par fusion , histoire de pas mourir idiots...
SQL pro , j'ai cru voir sur différents posts sur le forum que tu n'es pas "copain" avec la réplication par fusion , tu as l'air de la déconseillés dans beaucoup de cas..

[mikedavem]

La réplication de fusion est une réplication complexe à gérer et à maintenir et ayant un impact sur les performances de l'application. Il faut bien mesurer les enjeux de mise en place de ce type d'architecture.

Cela devient l'horreur surtout lorsque l'application s'adapte mal à ce type de topologie (gestion de conflits, divergence de données, ralentissement de la synchro, blocages ...). Je peux en témoigner pour avoir essuyer quelques plâtres depuis maintenant 3 ans chez un client.

++

[Michel.Priori]

Oui..les postes clients ne font qu'alimenter le serveur central, en aucun cas ils modifient les données existantes.

Pas tout bien compris là

Si le serveur central n'est qu'un 'LOG' des insert faits par les sites distant, la réplication n'est pas la bonne réponse.

Sinon,
je suis bien d'accord que la réplication de fusion est un sujet.
Pour autant c'est la seule solution pour avoir de l'autonomie des sites avec un besoin de base de données réparties.
Si on imagine 1 serveur central (A) et plusieurs sites indépendants(B, C, D).

Si chaque site "remonte" ses propres données sur A et qu'il en profite pour "redescendre" les données en lecture seule des autres sites, alors une (ou plusieurs) réplications transactionnelles sont envisageables.

Si tous les sites travaillent sur la même donnée et que le réseau n'est pas "fiable" alors la réplication de fusion s'impose (et ses contraintes aussi).