Discussion :

[Barsy]

Bonjour,

J'ai deux bases de données situées sur deux serveurs distants et je dois faire de la réplication "instantanée" entre ces deux base. J'ai donc opté pour une réplication transactionnelle en "push" car plus véloce et pour permettre l'exécution dans les deux sens, j'ai doublé cette réplication : C'est à dire que chaque serveur a une publication sur ses tables et chacun a un abonnement sur la publication de l'autre.
Et pour éviter les problèmes, j'ai supprimé la création de snapshot.

Je voulais savoir si vous voyiez des problèmes dans cette façon de faire.

Merci

[Syliano]

Hello,

Peut on avoir plus d'information ?

à quoi servent ses deux bases de données ?

[Barsy]

C'est essentiellement pour de la messagerie. Chacun des serveurs s'échange des données via ces tables.

[SQLpro]

Bonjour,

J'ai deux bases de données situées sur deux serveurs distants et je dois faire de la réplication "instantanée" entre ces deux base. J'ai donc opté pour une réplication transactionnelle en "push" car plus véloce et pour permettre l'exécution dans les deux sens, j'ai doublé cette réplication : C'est à dire que chaque serveur a une publication sur ses tables et chacun a un abonnement sur la publication de l'autre.
Et pour éviter les problèmes, j'ai supprimé la création de snapshot.

Je voulais savoir si vous voyiez des problèmes dans cette façon de faire.

Merci

Oui vous allez avoir de gros problème. En effet la réplication transactionnelle n'est pas conçue pour faire du FULL DUPLEX. par conséquent il va y avoir deux phénomènes :
1) écrasement des données
2) "résonance" de la réplication (A envoi une ligne à B pour mise à jour et B la renvoie pour mise à jour et A la renvoie...)

Deux solutions possibles :
1) vos données sont isolées logiquement au niveau des lignes => réplication transactionnelle Peer to Peer possible
2) n'importe quelle ligne peut être mise à jour par n'importe quel serveur => réplication de fusion.

Pour cette dernière attention... si vous répliquez toute la base (solution inepte) vous avez inintérêt à avoir des tuyaux très haut de gamme et doper vos serveurs, surtout si vous voulez l'avoir en instantané (dès que possible...)

Pour information : aucune solution de réplication de données n'est synchrone ! Prévoyez une latence minimum, par exemple 1 minute.

A +

[Barsy]

Alors après plusieurs tests, je ne constate pas de problèmes. C'est à dire :

- La latence est de quelques secondes (de 2 à 5), c'est très suffisant dans mon cas (les deux serveurs sont situés dans une même baie).
- Je n'ai pas de boucle, ce que je craignais le plus d'ailleurs. C'est à dire que si je réplique une ligne de A vers B, B la met à jour et ne renvoie pas de réplication à A. J'ai fait le test en générant 100000 lignes, la latence est montée à 20 secondes pour répliquer toutes ces lignes puis elle est retombée à 0 rapidement.
- Si je met à jour une donnée dans A, elle est envoyée à B sans qu'il n'y ait d'écrasement (c'est à dire que B ne vient pas remettre à jour A).

Bon, je ferai davantage de tests pour valider tout ça, ce que tu dis SQLPro c'est exactement les craintes que j'avais.

Après c'est pour de la messagerie, j'ai des tables pour échanger de A vers B et des tables pour échanger de B vers A donc au pire je peux faire la réplication que sur la moitié des tables dans chaque sens. Le but de faire la réplication sur l'ensemble dans les deux sens était de pouvoir faire remonter une donnée sur les messages envoyés et je voulais donc savoir s'il y avait un risque.

Je vous tiendrai informé si jamais un nouveau problème venait à se produire.