SQL 2008 - Scénarios de réplication

Version imprimable

08/09/2010, 18h43
marric01

SQL 2008 - Scénarios de réplication

Bonjour

Il y a plusieurs années, j'ai conçu un logiciel de gestion XYZ sous microsoft access 2000. À l'époque, il y avait la technologie de Replication Manager sous access qui pouvait permettre la synchronisation de .mdb de plusieurs clients vers un serveur central.

J'aimerais maintenant migrer et modifier mon application pour avoir mon back-end avec SQL 2008 R2.

J'ai lu vaguement les scénarios possible de replication.

Voici ma situation.

-Il n'y aurait qu'un seul serveur.
-Plusieurs clients peuvent avoir une réplique de la base de données et peuvent modifier,ajouter et supprimer des données.
-Le clients n'est pas toujours connecté et peut décider de synchroniser, par exemple, le soir.
-Les clients ne sont pas dans un "réseau" avec accès direct au serveur ... il faut pouvoir trouver un moyen de synchroniser via internet (FTP ???)
-Il est possible d'avoir des modification de structures de base de données seulement au niveau du serveur (C'était possible avec accès 2000 mais est-ce possible avec SQL Serveur ?)
- Le client aurait SQL 2008 Express édition
- Le serveur aurait la version SQL 2008 R2 Ent.
- Le front-end serait probablement VB (Visual studio 2010)

Est-ce possible selon mon scénario de faire de la réplication avec SQL 2008 R2 ? Si oui, qu'elle type de replication serait le mieux pour ce scénario ?

Est-ce que vous avez des liens internet interessant pour mon scénario ?

MErci beaucoup !!!! et bonne journée
08/09/2010, 18h51
Invité

Citation:

Envoyé par marric01

-Il n'y aurait qu'un seul serveur.
- Le client aurait SQL 2008 Express édition
- Le serveur aurait la version SQL 2008 R2 Ent.

C'est moi ou ça fait déjà deux ?
08/09/2010, 19h21
marric01

Citation:

Envoyé par Jerome_Mtl

C'est moi ou ça fait déjà deux ?

Il n'y a qu'un serveur central avec SQL Serveur 2008 R2 Ent. et plusieurs clients on une réplique de la base de données ;-)
08/09/2010, 20h56
mikedavem

Bonsoir,

La réplication de fusion semble la mieux adaptée pour votre scénario.

++
09/09/2010, 08h40
kagemaru

Est-ce que le flux ne va que vers la base centrale ou bien les données sont également renvoyées vers les clients ?
09/09/2010, 13h40
marric01

Citation:

Envoyé par kagemaru

Est-ce que le flux ne va que vers la base centrale ou bien les données sont également renvoyées vers les clients ?

Salut

Les modifications doivent-être possible dans les deux sens.

Sur le serveur ou se trouve la base de données centrale, il peut-y avoir des modifications. L'ensemble des clients peuvent également faire des modifications et envoyer ces modifications au serveur. Techniquement, tout les clients se partages le même contenu de la base de données.

Merci !
09/09/2010, 13h47
mikedavem

Donc une réplication de fusion sera le plus adaptée ..
Petite question tout de même : Est ce que les clients vont ou sont suceptibles de modifier les mêmes données ?

++
09/09/2010, 15h03
marric01

Citation:

Envoyé par mikedavem

Donc une réplication de fusion sera le plus adaptée ..
Petite question tout de même : Est ce que les clients vont ou sont suceptibles de modifier les mêmes données ?

++

Salut, oui il est possible que des usagers modifient les même données (Quoique très rarement). À l'époque de microsoft access et la replication. Le dernier à appliquer la modification dans mon logiciel était toujours celui qui gagnait. Je ne sais pas si c'est possible avec la replication SQL ??

J'oubliais, la replication avec les clients ne se fait que par internet.

Merci encore de vos réponses !

Richard
09/09/2010, 17h01
mikedavem

Peu importe le protocole utilisé pour synchroniser vos données avec votre architecture de réplication ..

Avec la réplication SQL Server vous avez une gestion des conflits plus poussée qu'avec Access. A vous de voir si vous voulez implémenter vos propres règles de gestion des conflits.

++
10/09/2010, 11h40
dbaffaleuf

- Quelle volumétrie pour la base et combien de tables à répliquer ? La réplication de fusion va ajouter une colonne unique et trois triggers par table, s'il y a beaucoup de tables la mise en place est assez compliquée.
- Il faut d'ores et déjà s'assurer que les mises à jour côté client ont lieu sur des jeux de données différents que les mises à jour côté serveur, pour minimiser les situations de conflit.
- La réplication de fusion est la plus compliquée à gérer. Il faudra certainement vous y former. Celà dit je suis d'accord avec mikedavem, à priori ça a l'air d'être la solution la plus adaptée.
10/09/2010, 14h41
marric01

1 pièce(s) jointe(s)

Citation:

Envoyé par dbaffaleuf

- Quelle volumétrie pour la base et combien de tables à répliquer ? La réplication de fusion va ajouter une colonne unique et trois triggers par table, s'il y a beaucoup de tables la mise en place est assez compliquée.
- Il faut d'ores et déjà s'assurer que les mises à jour côté client ont lieu sur des jeux de données différents que les mises à jour côté serveur, pour minimiser les situations de conflit.
- La réplication de fusion est la plus compliquée à gérer. Il faudra certainement vous y former. Celà dit je suis d'accord avec mikedavem, à priori ça a l'air d'être la solution la plus adaptée.

Bonjour,

Il va avoir environ 20 tables dans le processus de réplication. Le volume de données n'est pas très grand. Il s'agit d'un logiciel de gestion de ligue de hockey et la base de données acccess (mdb) fait environ 50mb avec 8 années de données (pour une ligue). Un processus DTS transfert les données de access vers SQL 2000 (Mon site web affiche les données du SQL 2000)

J'avais penser, dans ma nouvelle version sur SQL 2008, faire des écrans de gestions web qui pourrait modifier les données. Je suis certains que ce n'est pas dans les meilleurs pratiques que de modifier le data directement sur la base centrale de réplication... devrais-je faire un réplica sur le serveur même pour avoir une base dédier uniquement pour le site web (Elle agirait comme un client) ?

Le meilleur scénario aurait été que le client modifie uniquement les données sur le site web (pas besoin de réplication), mais je dois faire face à la stuation suivante : Les clients n'ont pas toujours accès à une connexion web live.

Voila ma situation et j'ai attaché un graphique simple de mon scénario cible

P.S. Quand vous parler de "la plus difficle à gérer" ... est-ce que vous parlez seulement au niveau de la gestion des conflits ou en général (Implantation et deploiement)?
13/09/2010, 18h03
dbaffaleuf

Pour moi une des deux bases centrales est en trop. Pourquoi y a-t-il une base web ? Et pourquoi la répli doit-elle être bidirectionnelle entre Web et principale ? Par exemple la partie lecture seule par le web peut se faire sur une base web répliquée avec de la réplication transactionnelle, et les mises à jour sur la base principale:

[MAJ] -> Principale (°) => REPLI TRANSAC => Web (°) <- [Consult HTTP]

Citation:

Envoyé par marric01

P.S. Quand vous parler de "la plus difficle à gérer" ... est-ce que vous parlez seulement au niveau de la gestion des conflits ou en général (Implantation et deploiement)?

La gestion des conflits est un gros morceau. Par rapport à la transactionnelle, il y a pas mal de tables systèmes en plus (tombstone, etc...). et la resynchronisation d'un client sans perdre ses mises à jour est plus compliquée qu'en transactionnelle où on va juste réappliquer un snapshot. Mais le plus important c'est de réduire le risque de conflit de mise à jour, sinon ça va vite devenir un cauchemar.
13/09/2010, 19h23
marric01

Citation:

Envoyé par dbaffaleuf

Pour moi une des deux bases centrales est en trop. Pourquoi y a-t-il une base web ? Et pourquoi la répli doit-elle être bidirectionnelle entre Web et principale ? Par exemple la partie lecture seule par le web peut se faire sur une base web répliquée avec de la réplication transactionnelle, et les mises à jour sur la base principale:

[MAJ] -> Principale (°) => REPLI TRANSAC => Web (°) <- [Consult HTTP]

La gestion des conflits est un gros morceau. Par rapport à la transactionnelle, il y a pas mal de tables systèmes en plus (tombstone, etc...). et la resynchronisation d'un client sans perdre ses mises à jour est plus compliquée qu'en transactionnelle où on va juste réappliquer un snapshot. Mais le plus important c'est de réduire le risque de conflit de mise à jour, sinon ça va vite devenir un cauchemar.

Les modifications aux données à partir du web se feraient directement sur la base centrale ? J'avais justement fait une repli de la base centrale pour permettre les modifications à la base de données à partir du web. Elle servirait à fournir les données pour l'Affichage sur le web et à permettre les modifications aux données à partir du web. Est-ce la bonne façon de faire ?