OVH Cloud OVH Cloud

Questions sur la réplication...

21 réponses
Avatar
Jérôme Quintard
Pour une nouvelle application je dois utiliser l'architecture suivante :

Un serveur SQL Local utilisé par notre application.
Deux serveurs IIS Distant en loadbalancing, avec sur chacun un serveur SQL
connecté.

Comment obtenir une synchronisation parfaite des données entre les deux
serveurs SQL distant (à cause du loadbalancing). Sachant qu'une publication
se fera en fusion, l'autre en transaction et que le local et relié au
distant par une simple connection ADSL.

J'espère avoir donner assez d'infos, merci pour votre avis....

Jérôme

10 réponses

1 2 3
Avatar
bruno reiter [MVP]
une transactionnelle bidirectionnelle va boucler.

si les deux serveurs IIS sont en interrogation seule, une transactionnelle
du serveur OLTP vers les 2 serveurs couplés à IIS me parait indiquée.

Tu fais une synchro des 2 abonnés toutes les minutes, il y aura une latence
minimale, mais impossible à éliminer totalement de quelques millisecondes.

br

"Med Bouchenafa" wrote in message
news:
Si tu as les ressources nécessaires (notamment temps) tu peux t'amuser à
mettre en place une réplication transactionnelle bidirectionnelle entre


SQL1
et SQL2

Concernant ce qui se fait chez les autres
Je connais notamment la solution d'Oracle pour avoir assister à une démo
Elle s'appelle RAC.
Voici un document Microsoft qui en parle



http://download.microsoft.com/download/e/8/e/e8ec4b71-bf13-4fd5-9af5-aabcbec859e6/RealityBehind_RAC.pdf.


--
Bien cordialement
Med Bouchenafa


"Jérôme Quintard" a écrit dans le
message de news:
>> Dans l'absolu, tu essaies de faire de la répartition de charge sur deux
>> SQL Server
>
> Oui... tu as compris, même si c'est une façon pas forcément
> "rigoureuse"...
>
>> La réplication n'est qu'un moyen (que je qualifie d'illusoire)
>
> Oui je comprend et tu as tout à fait raison...
>
>> Oui, un Abonné peut à son tour devenir Editeur
>
> ah ? bonne nouvelle... mais bon je sais pas si je vais vraiement gagner
> grand chose en terme de temps et au niveau supervision c'est pas
> terrible...
>
>> Moi, je reste persuader qu'un seul serveur attaqué par les deux IIS est
>> la meilleure solution
>
> Oui sauf qu'aujourhui on a investi dans 2 gros biProc au lieu d'un


quadri
> sur les conseils du fabricant. C'est assez délirant, surtout quand tu


sais
> ensuite que la solution proposé au départ ne fonctionne finalement pas


...
> (je parle du partage de la base sur un NAS) car au départ c'est notre
> fournisseur qui s'est fait valider la config par un ingé Microsoft...
>
>> Le jour où ton traffic se multiple par 3 ou 4, il faut espérer que tes
>> revenus se multiplient par un facteur plus important et que tu pourras
>> mettre en place un serveur plus conséquent
>
> Ok mais le jour ou ça ce développe de façon considérable je me vois mal
> passer d'un BiProc à un Quadri et d'un Quadri à un Octo en terme
> d'évolution c'est pas terrible... faut toujours racheter du matériel


plus
> gros plutôt que d'acheter "une extention" pour l'architecture


existante...
> Tu as une idée de la façon dont gère ce problème les sites internet à


très
> forte charge (microsoft, amazon et tant d'autres...) ?
>
>> Le clustering ne permet pas non plus de partager une base de données
>> entre deux serveurs
>
> Oui uniquement de la haute dispo... Mais donc sur SQL Server il existe
> aucune solution de partage de base ?! Sais tu si c'est possible sur
> d'autres SGBDR (Oracle, PostGreSQL, MaxDB, Firebird, Interbase ou
> autres...)
>
> En tout cas merci pour tes conseils med !!
>
> Jérôme
>




Avatar
Jérôme Quintard
> une transactionnelle bidirectionnelle va boucler.



ok merci pour la définition

si les deux serveurs IIS sont en interrogation seule, une transactionnelle
du serveur OLTP vers les 2 serveurs couplés à IIS me parait indiquée.



Ok

Tu fais une synchro des 2 abonnés toutes les minutes, il y aura une
latence
minimale, mais impossible à éliminer totalement de quelques millisecondes.



Oui ça je m'attendais pas à moins :) :) :)

Merci à tous !
Avatar
Jérôme Quintard
Par contre quel avantage j'aurrai à utiliser une réplication
transactionnelle bidirectionnelle par rapport à une fusion classique ?? Ce
type de méthode ne possède aucune résolution de conflit non ? Quelqu'un
aurrait un protocole pour mettre ça en place, je trouve pas trop de doc pour
SQL Server ??

Jérôme
Avatar
Med Bouchenafa
Bruno,
La réplication bidirectionnelle ne boucle pas indéfiniment
Si le siteA modifie une donnée, elle est répliquée vers le siteB mais ce
dernier ne la réplique pas à nouveau vers le siteA
Voir @loopback_detection dans l'Aide En Ligne.
Il y a un exemple complet de mise en oeuvre ici
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/replprog/rp_replsamp_3ve6.aspJérôme,Quel avantage à utiliser la réplication transactionnelle par rapport à laréplication par fusion ?Dans une réplication transactionnelle, l'unité de réplication est latransaction.Dans une réplication par fusion, l'unité de réplication est la ligne.Avec une réplication transactionnelle, tu ne risques pas d'avoird'incohérence de données entre tes deux sites à un moment donnéL'ensemble de données modifiées par une transaction est répliqué ou pas.Alors que la réplication par fusion peut répliquer une partie et remettre àplus tard une autre partie.Mais le choix dépendra des impératifs de chaque application.Il est vrai que le point faible de la réplication transactionnellebidirectionnelle reste la détection et résolution de conflits.Une fois, ce problème résolu, elle serait une solution idéale pour faire duload balancing SQL Server.SQL Server 2005 proposera un autre type de réplication (Réplication Peer toPeer).Cela ce rapproche beaucoup de la réplication transactionnellebidirectionnelleJe n'ai pas vraiment eu le temps de regarder comment ce nouveau type deréplication gère les conflits.Je ne suis cependant pas très optimiste car Microsoft ne fait pas beaucoupde pub sur le sujet.--Bien cordialementMed Bouchenafa"bruno reiter [MVP]" <remove.this! a écrit dans le messagede news: % une transactionnelle bidirectionnelle va boucler.>> si les deux serveurs IIS sont en interrogation seule, une transactionnelle> du serveur OLTP vers les 2 serveurs couplés à IIS me parait indiquée.>> Tu fais une synchro des 2 abonnés toutes les minutes, il y aura unelatence> minimale, mais impossible à éliminer totalement de quelques millisecondes.>> br>> "Med Bouchenafa" wrote in message> news: Si tu as les ressources nécessaires (notamment temps) tu peux t'amuser à>> mettre en place une réplication transactionnelle bidirectionnelle entre> SQL1>> et SQL2>>>> Concernant ce qui se fait chez les autres>> Je connais notamment la solution d'Oracle pour avoir assister à une démo>> Elle s'appelle RAC.>> Voici un document Microsoft qui en parle>>>http://download.microsoft.com/download/e/8/e/e8ec4b71-bf13-4fd5-9af5-aabcbec859e6/RealityBehind_RAC.pdf.>>>>>> -->> Bien cordialement>> Med Bouchenafa>>>>>> "Jérôme Quintard" a écrit dans le>> message de news: >> Dans l'absolu, tu essaies de faire de la répartition de charge surdeux>> >> SQL Server>> >>> > Oui... tu as compris, même si c'est une façon pas forcément>> > "rigoureuse"...>> >>> >> La réplication n'est qu'un moyen (que je qualifie d'illusoire)>> >>> > Oui je comprend et tu as tout à fait raison...>> >>> >> Oui, un Abonné peut à son tour devenir Editeur>> >>> > ah ? bonne nouvelle... mais bon je sais pas si je vais vraiement gagner>> > grand chose en terme de temps et au niveau supervision c'est pas>> > terrible...>> >>> >> Moi, je reste persuader qu'un seul serveur attaqué par les deux IISest>> >> la meilleure solution>> >>> > Oui sauf qu'aujourhui on a investi dans 2 gros biProc au lieu d'un> quadri>> > sur les conseils du fabricant. C'est assez délirant, surtout quand tu> sais>> > ensuite que la solution proposé au départ ne fonctionne finalement pas> ...>> > (je parle du partage de la base sur un NAS) car au départ c'est notre>> > fournisseur qui s'est fait valider la config par un ingé Microsoft...>> >>> >> Le jour où ton traffic se multiple par 3 ou 4, il faut espérer que tes>> >> revenus se multiplient par un facteur plus important et que tu pourras>> >> mettre en place un serveur plus conséquent>> >>> > Ok mais le jour ou ça ce développe de façon considérable je me vois mal>> > passer d'un BiProc à un Quadri et d'un Quadri à un Octo en terme>> > d'évolution c'est pas terrible... faut toujours racheter du matériel> plus>> > gros plutôt que d'acheter "une extention" pour l'architecture> existante...>> > Tu as une idée de la façon dont gère ce problème les sites internet à> très>> > forte charge (microsoft, amazon et tant d'autres...) ?>> >>> >> Le clustering ne permet pas non plus de partager une base de données>> >> entre deux serveurs>> >>> > Oui uniquement de la haute dispo... Mais donc sur SQL Server il existe>> > aucune solution de partage de base ?! Sais tu si c'est possible sur>> > d'autres SGBDR (Oracle, PostGreSQL, MaxDB, Firebird, Interbase ou>> > autres...)>> >>> > En tout cas merci pour tes conseils med !!>> >>> > Jérôme>> >>>>>>>
Avatar
Med Bouchenafa
Bruno,
La réplication bidirectionnelle ne boucle pas indéfiniment.
Si le siteA modifie une donnée, elle est répliquée vers le siteB mais ce
dernier ne la réplique pas à nouveau vers le siteA
Voir @loopback_detection dans l'Aide En Ligne.
Il y a un exemple complet de mise en oeuvre ici
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/replprog/rp_replsamp_3ve6.aspJérôme,Quel avantage à utiliser la réplication transactionnelle par rapport à laréplication par fusion ?Dans une réplication transactionnelle, l'unité de réplication est latransaction.Dans une réplication par fusion, l'unité de réplication est la ligne.Avec une réplication transactionnelle, tu ne risques pas d'avoird'incohérence de données entre tes deux sites à un moment donné.L'ensemble de données modifiées par une transaction est répliqué ou pas.Alors que la réplication par fusion peut répliquer une partie et remettre àplus tard une autre partie.Mais le choix dépendra des impératifs de chaque application.Il est vrai que le point faible de la réplication transactionnellebidirectionnelle reste la détection et résolution de conflits.Une fois, ce problème résolu, elle serait une solution idéale pour faire duload balancing SQL Server.SQL Server 2005 proposera un autre type de réplication (Réplication PeertoPeer).Cela ce rapproche beaucoup de la réplication transactionnellebidirectionnelle.Je n'ai pas vraiment eu le temps de regarder comment ce nouveau type deréplication gère les conflits.Je ne suis cependant pas très optimiste car Microsoft ne fait pas beaucoupde pub sur le sujet.Bien cordialementMed Bouchenafa
Avatar
Med Bouchenafa
Bruno,
La réplication bidirectionnelle ne boucle pas indéfiniment.
Si le siteA modifie une donnée, elle est répliquée vers le siteB mais ce
dernier ne la réplique pas à nouveau vers le siteA.
Voir @loopback_detection dans l'Aide En Ligne.
Il y a un exemple complet de mise en oeuvre ici
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/replprog/rp_replsamp_3ve6.asp



Jérôme,
Quel avantage à utiliser la réplication transactionnelle par rapport à la
réplication par fusion ?
Dans une réplication transactionnelle, l'unité de réplication est la
transaction.
Dans une réplication par fusion, l'unité de réplication est la ligne.
Avec une réplication transactionnelle, tu ne risques pas d'avoir
d'incohérence de données entre tes deux sites à un moment donné.
L'ensemble de données modifiées par une transaction est répliqué ou pas.
Alors que la réplication par fusion peut répliquer une partie et remettre à
plus tard une autre partie.
Mais le choix dépendra des impératifs de chaque application.
Il est vrai que le point faible de la réplication transactionnelle
bidirectionnelle reste la détection et résolution de conflits.
Une fois, ce problème résolu, elle serait une solution idéale pour faire du
load balancing SQL Server.
SQL Server 2005 proposera un autre type de réplication (Réplication
PeertoPeer).
Cela ce rapproche beaucoup de la réplication
transactionnellebidirectionnelle.
Je n'ai pas vraiment eu le temps de regarder comment ce nouveau type de
réplication gère les conflits.
Je ne suis cependant pas très optimiste car Microsoft ne fait pas beaucoupde
pub sur le sujet.

Bien cordialement
Med Bouchenafa
Avatar
Jérôme Quintard
Donc Med dans mon cas tu me conseil quoi au juste ?

SQL0 -> SQL1 = Réplication bidirectionnelle
SQL0 -> SQL2 = Réplication bidirectionnelle

Sachant que SQL0 est local (dans mon entrerprise), SQL1/2 chez notre
hébergeur...

Merci pour tes conseils...
Avatar
Med Bouchenafa
Je te conseille surtout de tester car il n'y a pas de solution définitive
Au vue de ton architecture, il a plusieurs possibilités mais je pense que la
plus facile à mettre en oeuvre est la suivante:

Réplication Transactionnelle avec Mise à jour immédiate entre SQL0 comme
Editeur et SQL1/SQL2 comme Abonnés.
Mais je ne sais pas si cela convient fonctionnellement.

La réplication bidirectionnelle necessiste pas mal de boulot.



--
Bien cordialement
Med Bouchenafa


"Jérôme Quintard" a écrit dans le
message de news:
Donc Med dans mon cas tu me conseil quoi au juste ?

= Réplication bidirectionnelle
SQL0 -> SQL2 = Réplication bidirectionnelle

Sachant que SQL0 est local (dans mon entrerprise), SQL1/2 chez notre
hébergeur...

Merci pour tes conseils...



Avatar
Jérôme Quintard
Merci med c'est effectivement ce que je pensais...
Avatar
Houdini
Bonjour,

Il y a peut-être une solution avec un produit Double-Take de SunbeltSoftware
(siège à Paris - contact efficace). Il permet entre autre de faire de la
réplication, du clustering ... pour ceux qui ne possède pas de version
entreprise (sql ou Win).

Cordialement,
Houdini

"Jérôme Quintard" a écrit :

Merci med c'est effectivement ce que je pensais...





1 2 3