Discussion :

[Invité]

Bonjour à tous.

Voici le contexte:
Nous avons plusieurs sites distants. Chacun de ces sites possèdent un serveur de base de données (SQL Server 2008 R2). Les données sont partagées entre les différents sites via une réplication de fusion. Sont présent aussi sur chaque site des POS (Point Of Sale) qui embarquent chacune un SQL Server 2008 R2 Express et synchronise les données avec le serveur central du site.

Pour schématiser on a:

• Un site principal 'X' avec:
• Un serveur SQL 'XSQL'
• Deux POS 'X1' et 'X2'
• Un sous-site 'A' avec:
• Un serveur SQL 'ASQL'
• Deux POS 'A1' et 'A2'
• Un sous-site 'B' avec:
• Un serveur SQL 'BSQL'
• Deux POS 'B1' et 'B2'

Les différentes synchronisations sont:

• Les postes 'X1' et 'X2' se synchronisent avec le serveur 'XSQL' via une réplication de fusion.
• Les postes 'A1' et 'A2' se synchronisent avec le serveur 'ASQL' via une réplication de fusion.
• Les postes 'B1' et 'B2' se synchronisent avec le serveur 'BSQL' via une réplication de fusion.
• Les serveurs 'ASQL' et 'BSQL' se synchronisent avec le serveur 'XSQL' via une réplication de fusion.

Le problème:
Dans certains cas des postes peuvent être en mode déconnecté et ne sont jamais relié au réseau, ni à internet. Comment gérer la synchronisation dans ce cas ?

La solution employée de réplication de fusion est-elle la bonne ?
Devons nous passer par une réplication d'instantanée (snapshot) dans le cas du mode déconnecté ?
J'ai vu qu'il existait un Framework de synchronisation, Microsoft Sync Framework, ceci serait-il adapté à notre cas ? Quels sont les plus et les moins par rapport aux solutions de réplication inclus avec SQL Server ?

Merci à tous.

[SQLpro]

Le problème:
Dans certains cas des postes peuvent être en mode déconnecté et ne sont jamais relié au réseau, ni à internet. Comment gérer la synchronisation dans ce cas ?

Sérieusement ???

Il vous reste, les signaux de fumées, la lettre postale, le téléphone RTC, la CB et que sais-je encore !

A +

[Invité]

Sérieusement ???

Hélas oui mais c'est un cas vraiment rare

Il vous reste, les signaux de fumées, la lettre postale, le téléphone RTC, la CB et que sais-je encore !

J'avais pensé aussi au pigeon voyageur mais hélas le client ne semble pas intéressé . Je pensais plus me tourner vers une solution d'export des données vers un stockage externe et ensuite importer ces données sur le serveur central mais je ne sais pas si une solution existe déjà au sein de SQL Server ou au sein d'un autre outil.

A +

[SQLpro]

Je pensais plus me tourner vers une solution d'export des données vers un stockage externe et ensuite importer ces données sur le serveur central mais je ne sais pas si une solution existe déjà au sein de SQL Server ou au sein d'un autre outil.

Toute ces solutions supposent qu'à un moment ou un autre vous ayez accès au réseau ! Si tel est le cas il suffit alors de faire une réplication qui se fait dès connexion au réseau !

A +

[Invité]

Bonjour,

Toute ces solutions supposent qu'à un moment ou un autre vous ayez accès au réseau ! Si tel est le cas il suffit alors de faire une réplication qui se fait dès connexion au réseau !

A +

Les solutions proposées ne sont peut-être pas les bonnes. Le seul accès possible au poste sera l'accès physique avec transfert des données vers un stockage externe qui ensuite sera branché au serveur principal. Est-il possible d'exporter les "logs" de transactions SQL et de les rejouer sur un autre serveur ?

Merci

[SQLpro]

Les "logs" de transactions supposent une base strictement identique d'un point de vue binaire ! Donc, pas possible par ce biais. Vous pouvez cependant utiliser CDC pour reproduire certaines requêtes...

A +