Discussion :

[Archi89]

Bonjour à tous,

Je vous sollicite à nouveau (après tant d’années) pour vous exposer un problème de taille.
Il s’agit du thème de la réplication en multi-sites.

Notre principe de fonctionnement actuel :
Nous travaillons sur un logiciel, qui utilise un server de fichier et une base SQL server. En gros, nos fichiers sont caractérisés par nos tables SQL. Pour l’instant, nos clients travaillent avec une seule base commune et là tout va bien.

Notre problématique :
Il y a maintenant des clients qui veulent travailler en multi-sites (par exemple : un en Chine, l’autre en Argentine). Et là, vient le problème de l’envoie de données. En effet, la connexion d’un site à l’autre est beaucoup trop lente. Actuellement, ils ont décidé de travailler avec deux bases différentes et nous avons développé une commande d’exportation de données qui exporte les fichiers d’une base à l’autre. Mais les vas et viens provoquent une certaine divergence dans le temps entre les deux bases.

Ce que nous voulons :
Avoir une seule base commune aux deux en optimisant les temps de transfert bien sûr. Mais si on imagine que la connexion internet n’est plus possible, un des sites ne peut plus travailler et c’est inacceptable.

Les solutions :
Voilà que je me tourne vers vous, pour, dans un premier temps, exposer les solutions qui existent. Nous avons notamment exploré les sujets de réplications entre base (sql mirroring, groupes de disponibilité, …). Le gros challenge est que la lecture et l’écriture de données puissent être possible dans les bases "secours" et surtout le "merge" de la base secours vers la base maitresse.

Ps : Je tiens à vous remercier d’avance et je voulais vous remercier aussi pour la qualité de votre site car même si je ne pose pas souvent de questions, je viens souvent lire ici et c’est une mine d’or (mieux qu’à l’école pour apprendre ).

[mikedavem]

Hello,

En prenant un compte ton besoin, vu de loin la réplication de fusion (MERGE) est un bon candidat à ton besoin et spécifiquement pour les points suivants:

- Multi master possible (lecture / écriture)
- Les sites peuvent être en autonomie en cas de coupure internet
- Réplication qui s'effectue au fil du temps (via exécution d'agents de réplication au travers de travaux SQL Server planifiés)

Juste prendre en compte l'impact de la réplication sur l'application (qui peut parfois exclure cette solution en fonction du contexte). En effet la réplication merge nécessite quelques adaptations plus ou moins non négligeables (liste non exhaustive):

- Ajout d'une colonne UNIQUEIDENTIFIER
- Ajout de triggers de réplication sur chaque table concernée par la réplication
- L'application doit aussi prendre en compte la réplication (quid des filtres de partitions, gestion des conflits etc ...)
- L'impact sur l'infrastructure qui doit évoluer (ajout de composants) avec la notion de publicateur, abonné et distributeur
- L'impact sur l'administration / monitoring de cette infrastructure
- L'impact des mises à jour (faire attention si des gros volumes de données doivent être répliqués d'un coup .. la réplication peut avoir du mal à les absorber surtout si les liens réseaux sont lents ...)

++

[SQLpro]

...Nous avons notamment exploré les sujets de réplications entre base (sql mirroring, groupes de disponibilité, …). Le gros challenge est que la lecture et l’écriture de données puissent être possible dans les bases "secours" et surtout le "merge" de la base secours vers la base maitresse.

sql mirroring, groupes de disponibilité
Comme son nom l'indique les groupes de disponibilité sont dédiés à la haute disponibilité, pas du tout à copier des données d'une base à l'autre en synchronisant les écritures faites de part et d'autre. Idem pour le mirroring.


il faut distinguer ce qui est de la
DUPLICATION des données => base strictement identique à l'originale, attendant d'être exploité en cas de perte de l'original, assurant les services de haute disponibilité…
de la
REPLICATION des données => différentes bases qui n'ont pas forcément les mêmes tables ni les même informations et dans lesquelles on propage certaines informations entre elles. Ceci permettant d'assurer du "scale out" c'est à dire étendre le service des données, soit par topologie (des serveurs à Paname, Xanadu et Tonbouctou), soit par emplacement (par exemple, sur un même lieu, un serveur ayant les client de A à M et l'autre de N à Z afin d'absorber plus de charge).

Vous êtes bien évidemment dans le 2e cas : réplication de données.

Comme vous voulez assurer une réplication de données de type "full duplex" (mise à jour possible sur tous les serveurs), les outils pour ce faire sont :

• la réplication de type MERGE
• service broker.

A +

[Archi89]

Merci pour vos réponses.

En réalité, on veut seulement écrire dans la base maître, les identifiants auto incrémentés doivent pointer sur un objet unique (nos fichiers).
Là par exemple, en cas de coupure internet, la base secondaire devient accessible en écriture, il va y avoir une divergence donc (par ex l'id 560, en base secondaire, pointera sur l'objet patate, tandis que l’objet 560, sur la base maître, sera une tomate).
Ensuite lorsque la connexion sera redevenue possible, on exportera l'objet patate sur la base maître et son id sera 587 par ex.
A ce moment, la base secondaire sera supprimée puis la base maître sera copiée à l'identique (on re-converge).
Je ne sais pas si j'ai été clair.

Nous pensions qu'une utilisation des groupes de synchro serait une bonne approche. Vous en pensez quoi avec ce fonctionnement ?

Bonne soirée.
A +

[SQLpro]

Nous pensions qu'une utilisation des groupes de synchro serait une bonne approche. Vous en pensez quoi avec ce fonctionnement ?

Totalement foireux !

la réplication de fusion (MERGE) répond à 100 % de vos besoins. Commencez par l'étudier.

A +

[Invité]

Il faut redéfinir l'objectif. Notre objectif est d'obtenir une meilleure disponibilité dans une configuration multi-site aux quatre coins du globe, il ne s'agit pas de répondre à une problématique de merge entre bases de données. Nous souhaitons éviter les problématiques de merge car elles sont très compliquées à résoudre, nous avons plus de 80 tables avec des relations complexes. Nous disposons déjà de notre propre système de transport des données de base de données à base de données, ce système permet d'effectuer les merges, c'est un système compliqué, le recoder sous la forme d'un merge SQL serait une sacré travail. D'autant plus que la problématique n'est pas "SQL Server only", le merge a des conséquences sur les fichiers fonctionnant en parallèle de la base de données. SQL Server ne peut pas gérer en même temps les conséquences en terme de merge sur des fichiers qui sont stockés sur des serveurs de fichiers distants (en accès TCP, FTP).

L'objectif principal est de s'affranchir des problématiques de latence qu'impose une connexion sur de grandes distances, un ping défavorable de 200ms nous pose problème pour assurer de bonnes performances dans le logiciel. D'où la solution de haute disponibilité consistant à avoir une base primaire en écriture sur un site et x bases secondaires en lecture seule disponibles sur les autres sites (Always on Availability Groups - groupes de disponibilité). Ceci permet de faire disparaître le problème de la latence sur plus de >80% des requêtes, car >80% des requêtes sont en lecture. Pour les requêtes en écriture nous acceptons de payer le coût du ping au site lointain. La question que nous nous posons, c'est le prix de SQL Server Enterprise pour obtenir les groupes de disponiblités (10,000 $ à rajouter par rapport à SQL Server Standard). C'est peut-être non bloquant car nous allons adresser des multi-nationales qui ont les moyens. Mais nous commençons à nous demander s'il ne faudrait pas envisager en plus un autre système de réplication moins cher, en développant notre propre SQL Agent de réplication par exemple (une réplication basique des tables, strictement à l'identique, sans merge). Sachant qu'il faudra que cette réplication s'effectue rapidement, nous pouvons accepter un certain décalage de 1 minute dans la réplication, mais il faut pas que ça aille au delà, après ça deviendra trop pénalisant car les utilisateurs travaillent en collaboratif.

[SQLpro]

Il faut redéfinir l'objectif. Notre objectif est d'obtenir une meilleure disponibilité dans une configuration multi-site aux quatre coins du globe, il ne s'agit pas de répondre à une problématique de merge entre bases de données. Nous souhaitons éviter les problématiques de merge car elles sont très compliquées à résoudre, nous avons plus de 80 tables avec des relations complexes. Nous disposons déjà de notre propre système de transport des données de base de données à base de données, ce système permet d'effectuer les merges, c'est un système compliqué, le recoder sous la forme d'un merge SQL serait une sacré travail. D'autant plus que la problématique n'est pas "SQL Server only", le merge a des conséquences sur les fichiers fonctionnant en parallèle de la base de données. SQL Server ne peut pas gérer en même temps les conséquences en terme de merge sur des fichiers qui sont stockés sur des serveurs de fichiers distants (en accès TCP, FTP).

Je pense que vous n'avez pas compris et toujours pas étudié les papiers que l'on vous a référencés. Il ne s'agit pas de la commande SQL MERGE, mais d'une réplication de fusion dite "MERGE REPLICATION" qui se base sur un ensemble de mécanismes intégrés à SQL Server depuis la version 7 de SQL Server et qui a été développé par Microsoft sous la houlette de Jean-Yves DEVANT avec un équipe de plusieurs dizaines de développeur de 1998 à 2008. Ceci fonctionne très bien et est utilisé par de nombreux gros client comme FNAC.com (plusieurs To de data dans différentes bases répliquées - plusieurs centaines de tables...) ou encore Eurocopter (devenu AIRBUS hélicopter) pour la base de maintenance mondiale (réplication sur plusieurs dizaines de pays...)

Les éventuels conflits de réplication (car il y en aura toujours) peuvent être traités de manière automatique par la mise en place de règles du genre :

• Le dernier qui met à jour est prioritaire
• Un ordre de priorité est défini pour chaque serveur (par exemple Serveur de paris, priorité 10, Lyon priorité 7, Marseille priorité 5...)
• etc.

Toute la mécanique (données à prendre en compte, propagation des informations, vecteur de communication...etc) est géré par les outils MS. Vous n'avez qu'à faire la mise en place de la chose.

Il semble donc, que par méconnaissance vous ayez réinventé la roue, mais une roue peu fiable et qui aujourd'hui vous montre ses limites. C'est dommage car avec un peu de formation initiale, vous auriez économisé énormément de travail, maintenance et déboires !

L'objectif principal est de s'affranchir des problématiques de latence qu'impose une connexion sur de grandes distances, un ping défavorable de 200ms nous pose problème pour assurer de bonnes performances dans le logiciel. D'où la solution de haute disponibilité consistant à avoir une base primaire en écriture sur un site et x bases secondaires en lecture seule disponibles sur les autres sites (Always on Availability Groups - groupes de disponibilité). Ceci permet de faire disparaître le problème de la latence sur plus de >80% des requêtes, car >80% des requêtes sont en lecture.

Votre latence va sans doute disparaître pour les lectures, mais vos lectures ne verrons que les données acquises ce qui risque de conduire à des problématiques plus grave encore...
En effet effectuer des écritures sur un serveur et des lectures sur un autre répliqué en mode asynchrone, va vous réserver quelques surprises.
Exemple :

• L'utilisateur rentre un nouveau client => INSERT sur serveur distant
• L'utilisateur affiche ensuite la liste des clients => SELECT sur serveur local (à la suite de l'INSERT)
• Compte tenu du mode asynchrone de propagation dans AlwaysOn dans votre cas de figure, le nouveau client n'apparait pas.
• Que fait l'utilisateur ?
• Il le recrée ne le voyant pas !

Vous avez pourri votre base !

Dans une application interactive qui attaque une base de données, toutes les lectures et écritures doivent se faire sur la même base, les lectures pouvant être effectuées sur un réplicas synchrone. Seul les "batchs" peuvent être effectué sur une machine déportée en mode asynchrone (ce que nous avons fait par exemple pour GEODIS, pour tous les documents de transport qui sont édités - impression - sur une grappe de serveur en réplicas asynchrone ALwaysOn).

Pour les requêtes en écriture nous acceptons de payer le coût du ping au site lointain. La question que nous nous posons, c'est le prix de SQL Server Enterprise pour obtenir les groupes de disponiblités (10,000 $ à rajouter par rapport à SQL Server Standard). C'est peut-être non bloquant car nous allons adresser des multi-nationales qui ont les moyens. Mais nous commençons à nous demander s'il ne faudrait pas envisager en plus un autre système de réplication moins cher, en développant notre propre SQL Agent de réplication par exemple (une réplication basique des tables, strictement à l'identique, sans merge). Sachant qu'il faudra que cette réplication s'effectue rapidement, nous pouvons accepter un certain décalage de 1 minute dans la réplication, mais il faut pas que ça aille au delà, après ça deviendra trop pénalisant car les utilisateurs travaillent en collaboratif.

Le mode de réplication de fusion peut descendre jusqu'à "au fil de l'eau". mais cela n'est pas conseillé si vous avez beaucoup de trafic. Personnellement j'invite à y mettre 10 à 15 secondes.

Enfin, vous pouvez aussi étudier la transactionnelle "peer to peer" (traduit par réplication transactionnelle d'égal à égal) qui peut se combiner avec la répication de fusion. En gros, si les données de vos clients restent propre à chaque client et que, seules, quelques tables doivent être fusionnées, alors c'est vers cette combinaisons de réplication qu'il faut aller.

A +

[Invité]

Nous avons un système client-serveur qui intégre le fait que le client est toujours en retard par rapport au serveur. Comme dans Visual Studio, où les Pending Changes et Source Control dans une instance de l'application Visual Studio ne sont pas forcément en phase avec l'état côté serveur. Il y a à cet effet un bouton Refresh dans Visual Studio qui permet de resynchroniser les informations avec l'état du serveur. Dans notre logiciel nous fonctionnons de la même manière, nous acceptons que le cache des données côté client soit en retard. Pour gérer cette situation nous avons des mécanismes avec des identifiants qui permettent de savoir où en en est notre objet : est-il en retard par rapport au serveur... Donc gérer une situation où le base secondaire en lecture seule nous donne une information en retard par rapport à la base primaire n'est pas un problème pour nous. Pour l'exemple de l'utilisateur créé en double, nous avons déjà des tests qui évitent de créer des utilisateurs de manière concurrentielle. Dans notre cas l'application cliente n'effectue pas un accès simple à une base de données, le client passe par un service installé sur le serveur qui joue le rôle d'intermédiaire et assure une série de vérifications avec des locks avant d'écrire dans la base de données.

Les mécanismes de "Merge Replication" mis en place chez Aribus et FNAC est très bien, je ne le remets pas en cause et ne cherche pas à réinventer un mécanisme de merge. Mais comme indiqué nous ne souhaitons pas effectuer de merge de base de données ayant divergées, car ça aboutit à des résolutions de conflits impossibles. Il n'est pas possible dans notre cas de dire, je choisis l'information venant de gauche ou de droite, car nos utilisateurs perdront des semaines de travail. Et il n'est pas possible de merger ces 2 informations en une seule information, car ça n'a pas de sens (ça revient à vouloir merger le contenu de 2 fichiers binaires en un seul fichier). Nous souhaitons rester sur un système centralisé avec une serveur primaire qui décide des modifications pouvant être effectuées, et des bases secondaires en lecture seule qui suivent et assurent un workload de bonne qualité sur toute la planète. Des concurrents comme SolidWorks ont déjà adopté la solution Always On Availability, elles est aussi applicable dans notre cas. La question était donc de voir s'il existe un moyen de coder cette réplication simpliste (une base données donne exactement la même base ailleurs) avec un agent plutôt que de payer la facture de la licence SQL Server Enterprise.

[Archi89]

On observant ce schéma, on voit que le "publisher" envoie les données au "distributor" (qui peuvent être confondus?), donc la base mère est le "distributor" (c'est donc elle qui décide des objets Id) puis les données sont renvoyées au "publisher" et aux "subsribers". Si le "subscriber" demande l'insertion de données, il devient le "publisher", c'est bien ça?

[SQLpro]

Mais comme indiqué nous ne souhaitons pas effectuer de merge de base de données ayant divergées, car ça aboutit à des résolutions de conflits impossibles. Il n'est pas possible dans notre cas de dire, je choisis l'information venant de gauche ou de droite, car nos utilisateurs perdront des semaines de travail. Et il n'est pas possible de merger ces 2 informations en une seule information, car ça n'a pas de sens (ça revient à vouloir merger le contenu de 2 fichiers binaires en un seul fichier).

Comme c'est vous qui définissez la règle, vous pouvez indiquer devoir conserver les deux versions, mais dans ce cas, vous devrez "manuellement" (y compris par une tâche dautomatique développée sur votre serveur maître) rajouter une information de dédoublonnement.

Nous souhaitons rester sur un système centralisé avec une serveur primaire qui décide des modifications pouvant être effectuées,

Et donc la solution en réplication de fusion reste parfaitement applicable !

et des bases secondaires en lecture seule qui suivent et assurent un workload de bonne qualité sur toute la planète. Des concurrents comme SolidWorks ont déjà adopté la solution Always On Availability, elles est aussi applicable dans notre cas. La question était donc de voir s'il existe un moyen de coder cette réplication simpliste (une base données donne exactement la même base ailleurs) avec un agent plutôt que de payer la facture de la licence SQL Server Enterprise.

AlwaysOn est destiné à assurer la haute disponibilité. Pas la "sacalability" pour lequel ce n'est pas la mission première... utiliser une technologie a des fins détournées ne peut que vous nuire à moyen et long terme !

Encore une fois intéressez vous à la réplication de fusion !

A +

[Archi89]

Encore une fois intéressez vous à la réplication de fusion !

En fait, on veut exactement faire le mode always-on. C'est à dire, que les bases secondaires sont en lecture seule, on redirige donc les insertions sur le serveur maître puis il les réplique sur le serveur secondaire.
En mode offline (coupure internet), on peut insérer les données dans le server secondaire (il passe en mode écriture, là on diverge), mais ces changements sont en "attentes". Ensuite on exporte nos données, lorsque l'on retrouve internet, sur la base maître, en passant par nos mécanismes d'import/export, et ces données sont insérées via notre logiciel (très important pour nous). De nouvelles modifications sont donc apparues dans la base maître et ses données doivent être, ensuite, répliquées à l'identique sur les bases secondaires.
Est-ce possible de faire ceci via un agent de fusion? Redirection des insertions,... sur le server maître uniquement ? Le cas de fonctionnement dégradé (coupure internet) peut il être implémenté?
Via lecture, on a l'impression que le GUID sur chaque colonne est obligatoire pour faire de la fusion (merge), on a aussi l'impression que l'on peut insérer les données dans les bases secondaires puis il les fusionne (ce qu'on ne veut pas au final).
C'est un peu flou pour l'instant...

Et merci pour vos réponses.

[Invité]

Notre concurrent SolidWorks est un leader mondial de la CAO avec 3.5 millions de licences distribuées dans le monde, ils sont des partenaires privilégiés de Microsoft. J'ai tendance à croire que s'ils ont choisi "Always On Availability" pour répondre à cette problématique ils ne l'ont pas fait par hasard. En se référant à la page d'explication de Microsoft, nous voyons que "Always On Availability", permet d'effectuer de la répartition de charge en déportant le travail sur des bases secondaires en lecture seule (Décharger une charge de travail en lecture seule vers un réplica secondaire d’un groupe de disponibilité Always On : https://docs.microsoft.com/fr-fr/sql...ql-server-2017). Ceci sous-entend que l'application utilisant ce mécanisme sait gérer les conséquences en terme de décalage au niveau de la base secondaire, ce qui est notre cas et celui de SoildWorks.

"Always On" fait le job mais il a le défaut d'être cher car il faut une licence SQL Server Enterprise, alors que Standard va très bien à nos clients. Le "Merge Replication" peut faire le job mais semble être une solution détournée par rapport à ce que nous souhaitons. C'est pour cela que nous nous demandons s'il n'existe pas une implémenation plus simple dans notre cas, car nous n'avons aucune règle de fusion à appliquer, c'est une réplication bestiale des tables SQL de type mirroring. Mais la techno mirroring ne nous convient pas, car il ne peut y avoir qu'une seule base secondaire et la techno Mirroring est destinée à disparaître suite à l'apparition de "Always On". Nous allons ouvrir un ticket chez Microsoft dans le cadre de notre partenariat Gold pour avoir des informations complémentaires, nous vous tenons au courant des éléments de réponse qui seront donnés. Notre projet est en phase de pré-analyse, c'est pour l'instant de la prospection avec des spécs qui bougent jour après jour :-)

[mikedavem]

Hello,

Mais du coup ceci:

En fait, on veut exactement faire le mode always-on. C'est à dire, que les bases secondaires sont en lecture seule, on redirige donc les insertions sur le serveur maître puis il les réplique sur le serveur secondaire.

n'est-il pas antinomique à cela :

Ce que nous voulons :
Avoir une seule base commune aux deux en optimisant les temps de transfert bien sûr. Mais si on imagine que la connexion internet n’est plus possible, un des sites ne peut plus travailler et c’est inacceptable.

Dites moi si j'ai saisi correctement mais cela reviendrait à:
1- Redirigez toutes vos transactions applicatives depuis vos sites vers un serveur principal
2- Le serveur principal répliquerait vers les bases de données des différents secondaire qui se trouvent sur vos sites

Dans ce cas si la connexion réseau n'est plus possible alors vous risquez de vous retrouver dans la situation inacceptable que vous décrivez ici (à moins que cela ne soit un scénario accepté et sous contrôle dans votre cas). Est-ce que je me trompe?

La question était donc de voir s'il existe un moyen de coder cette réplication simpliste (une base données donne exactement la même base ailleurs) avec un agent plutôt que de payer la facture de la licence SQL Server Enterprise.

Je ne connais pas le nombre de sites que vous aurez mais il est clair que la facture risque d'être salée avec du AlwaysOn AG. Vous pourriez dans ce cas toujours intérêt à évaluer la réplication merge avec publication d'articles en lecture seule ou réplication transactionnelle puisque visiblement les écritures seraient toujours effectués depuis le publicateur centrale. Il n'est pas nécessaire avoir une édition Entreprise dans ce cas.

++

[Archi89]

Dites moi si j'ai saisi correctement mais cela reviendrait à:
1- Redirigez toutes vos transactions applicatives depuis vos sites vers un serveur principal
2- Le serveur principal répliquerait vers les bases de données des différents secondaire qui se trouvent sur vos sites

Dans ce cas si la connexion réseau n'est plus possible alors vous risquez de vous retrouver dans la situation inacceptable que vous décrivez ici (à moins que cela ne soit un scénario accepté et sous contrôle dans votre cas). Est-ce que je me trompe?

Oui sur les sites secondaires, lorsqu'ils créent un objet, les insertions doivent être redirigées vers le server maître (server de publication?) puis les réplique sur le server secondaire.
Si la connexion réseau n'est plus possible, alors l'insertion est dirigée sur le site secondaire (pas le choix). On diverge donc avec la base maître. On exporte ensuite nos objects, lorsque la connexion est re-devenue possible sur la base maître.
Un fois l'importation finie, on peut ensuite resynchroniser nos datas (le secondaire redevient l'image exacte du maître => suppression des nouvelles modifications de la base secondaire mais on l'accepte).

[mikedavem]

Dans ce cas il est certain que vous pouvez exclure AlwaysOn de vos solutions possibles.
Les bases de données sur les secondaires ne sont qu'en lecture seules donc aucune chance de pouvoir dedans en cas de coupure réseau et redirection des connexions clientes. Comme expliqué par SQLPro AlwaysOn est une solution orientée HA/DR et ne correspond pas vraiment à ce genre de besoin. (si vous auriez uniquement du Reporting sur vos sites secondaires à la rigueur ...)

Par ailleurs il est question de resynchroniser les données des serveurs "offlines" depuis les sites vers le serveur principal pour rétablir une synchronisation parfaite.
Est-ce qu'il peut exister des scénarios où 2 sites puissent mettre à jour la même donnée dans un mode où ils devraient le faire en local puisque plus de connexion réseau avec le maître? Si oui quelles solutions dans votre cas pour savoir qui doit gagner?

++

[Archi89]

On avait juste vu qu'on pouvait basculer en mode écriture aussi avec les groupes de dispo...
Mais bon, on étudie aussi l'agent de fusion et on se demande si notre cas est paramétrable "facilement".

Nous détectons les conflits via nos imports/exports déjà. Ce n'est pas un pb.
Pour faire simple :

Mode normal : Toutes les transactions sont redirigés vers le server maître puis les réplique sur les secondaires.
Mode internet coupé : Les transactions sont redirigées vers le server localement. On travaille en local, on exporte ensuite le travail effectué puis on importe via le server maître. La base secondaire est périmée, et une fois l'import fait, hop on déclenche la synchro. La base secondaire est re-devenu une copie conforme. (Tant pis si ils n'ont pas tout exporté).
Bien entendu le mode offline est UNIQUEMENT un mode de secours. C'est pour dépanner.

[StringBuilder]

Au risque de m'attirer les foudres, il existe une solution "simple" pour s'assurer que les chronos des différents sites ne se marchent pas sur les pieds.

Il suffit de gérer le numéro de site dans votre chrono.

Vous utilisez des ID 64 bits (bigint)
Sur le site 1, vous ajoutez systématiquement 1 * 2^32 à tous vos ID générés.
Sur le site 2, vous ajoutez systématiquement 2 * 2^32 à tous vos ID générés.
Etc.

Ainsi, lorsque vous faites la synchro, les ID générés par un site ne peuvent pas du tout entrer en collision avec ceux générés par un autre site.

Le seul véritable avantage de cette solution, mise à part qu'elle est très simple à mettre en œuvre, c'est qu'elle n'est pas contrainte à un produit, et encore moins à une édition (vous pouvez tout à faire avoir un site sous SQLite et un autre sous MySQL).

[SQLpro]

C 'est que j'ai préconisé il y a fort longtemps pour le site de fnac.com... Les ID des PK de chaque table de chaque serveur sont décalés par modulo. Sur le serveur 0 en module 0 de n serveur, 0 sur le serveur 1 de modulo 1, etc. Et en plus on peut savoir d’où est venu la ligne.

MAIS : il faut que TOUTES les tables aient une PK constituée d'une seule et unique colonne de type entier avec les propriétés IDENTITY et NOT FOR REPLICATION (pour cette dernière c'est mis automatiquement par les assistant de réplication de fusion).

A +

[Archi89]

Effectivement avec ceci les clés primaires ne peuvent pas se croiser. Mais on ne peut pas imposer une telle contrainte dans notre cas, les clés sont assez complexes...
L'idée d'un server lié qui redirige les transactions sur le server maître avec l'agent de fusion qui les réplique sur les secondaires est elle envisageable?

[mikedavem]

Oui mais gros impact sur la performance si c'est un point important

++