Discussion :

[shaffy]

Bonjour,

Bien que le sujet semble, après recherche, redondant, j'aimerai connaître les implications au niveau de l'administration qu'engendre le mode de réplication de fusion.

Situation : Mon client, disposant de son site principal à un endroit X, décide de délocaliser sa saisie dans un endroit Y.
En l'état, un seul serveur MSSQL2005 (nous l'appellerons "A") est existant. pour le moment, la saisie par les postes du site "B" se déroule en bureau en distance sur un poste dédié à cela mais n'est pas satisfaisante.
Sa demande est claire : Dupliquer "A" sur le site délocalisé par "B" et synchroniser "A" et "B" via le VPN une fois par jour.
A noter que "A" et "B" seront deux serveurs jumeaux en tous points.

Pour ce faire, le mode de réplication de fusion semble parfaitement adapté.
(il est question d'exploiter les données sur les deux sites)

[ petite question au passage : est-il plus intelligent, avant d'initialiser une quelconque "synchronisation" de restaurer la dernière version de la base sur le nouveau serveur, en l'occurence "B", où alors de laisser cette première synchro à la charge du processus d'abonnement ? ]


Dans cette configuration, et en admettant l'hypothèse que l'on définisse une priorité absolue au site "A" en cas de modifications concurrentes, doit-je imaginer qu'une fois cette réplication installée, un lourd travail d'administration m'attends encore ?

Toujours dans cette configuration, (serveurs en tous points identiques) puis-je imaginer que la mise en place de cet outil se fasse "sans accrocs majeurs" ?

Merci d'avance des retours d'expérience que vous voudrez bien me laisser, j'ai peur que cela ne soit pas aussi aisé qu'il n'y paraît.

[PierreDelcroix]

Actuellement, je travaille avec 8 serveurs synchronisés et cela fonctionne bien, mais j'ai un nombre de remarques :

1. La modification des tableaux est plus compliquée.

2. Dans notre application, on ne peut presque jamais changer les données d'un autre site, par exemple, les données de personnel peuvent être modifiées uniquement dans le site au le membre du personnel est présente.

3. Il peut durer parfois longtemps pour synchroniser tous les données, un delay d'une heure n'est pas rare.

4. Il dure longtemps pour le faire en marche, mais une fois quand tous est mise en route, ça roule très bien.

[shaffy]

4. Il dure longtemps pour le faire en marche, mais une fois quand tous est mise en route, ça roule très bien.

bonjour et merci pour votre retour.
Je suis assez surpris, s'agit-il de la première synchronisation dont vous parlez ? j'avais l'impression que l'outil était plutôt rapide à mettre en oeuvre ?

Concernant le point 3 de votre réponse, un délai d'une heure ne me semble pas excessif, surtout dans la mesure où, dans mon cas, il ne s'agit que de deux serveurs et que ceux ci auraient la nuit s'il le faut pour se synchroniser (pas d'activités nocturnes).

Merci encore pour votre retour d'expérience.
Fabien.

[PierreDelcroix]

j'avais l'impression que l'outil était plutôt rapide à mettre en oeuvre

Techniquement, vous avez raison, mais c'est surtout le "entourage" qui doit être examiné bien. Je pense par exemple à triggers et des procédures stockées, les champs et les tableaux qui ne doivent pas être déplacés...

Il est parfois meilleur de lancer une procédure stockée pour faire des statistiques deux fois, que de lancer une fois la procédure et de synchroniser les données.

On peut synchroniser plus rapide, mais disons que le réseau et les serveurs ne l'aime pas tellement. Mais, on diminue bien la chance de "collisions" de données.

[bodygard]

est ce qu'il est possible d'implémenter une replication de fusion avec la version Express de SQL Server 2005 ?

[shaffy]

est ce qu'il est possible d'implémenter une replication de fusion avec la version Express de SQL Server 2005 ?

Apparemment, oui.
(le test de réplication de fusion que je dois faire bientôt sera fait entre 1 MSSQL & 1 express).

Seule différence notable : le MSSQL devra servir de "serveur de publication" auquel l'express sera abonné.

Corrigez moi si je me trompe.