Discussion :

[djraphi23]

bonjour,

je commence un projet qui comporte 3 bases de donnees sql server 2008. le but serait de synchroniser les 3 bases de donnees a chaque fois qu'une d'entre elles est soumis a un INSERT/DELETE/UPDATE...etc. j'ai pense a la merge replication que propose sql server. donc chaque base bdd serait a la fois client et serveur pour les replications. cela posera un probleme ? avez vous une meilleure idee ? merci

[SQLpro]

Quel intérêt ? La réplication de fusion est la plus :

• complexe
• gourmandes en ressources
• incohérente (il faudra arbitrer les conflits)

Commencez par nous décrire votre besoin fonctionnel !

A +

[djraphi23]

ok,

a l'heure actuelle, il ya un seul serveur avec la base de donnee. l'entreprise desire faire du load balancing avec la base de donnee et des scripts ruby. elle souhaite rajouter 2 nodes contenant les scripts ruby et la base de donnee dans chaque serveur. les bases de donnees (3 en tout) doivent etre synchronisees en temps reel. exemple : lorsqu'un enregistrement dans une des bases de donnees est ajoute ou modifie, il faudrait que la modification soit egalement faite presque instantanement dans les 2 autres base de donnees.

est ce possible et pas trop lourd de synchroniser ces 3 bdd de maniere presque instantanee ?

[SQLpro]

Vous faites fausse route sur les concepts. Il n'y a aucun intérêt à faire du lload balancing sur une base de données avant d'avoir épuisé le scale up. Cela va couter extrêmement cher : en machine en licences et en ressources, surtout si vous voulez que ceci soit quasiment synchrone. AVez vous un dba en permanence ? Quelle est la taille de votre serveur ? quel est le nombre potentiel d'utilisateur ? Dans quel but voulez vous faire du load balancing (c'est bon pour les serveur web ou d'objet, mais catastrophique pour les SGBDR !) ???

A +

[djraphi23]

merci pour la reponse,

j'ai parle a l'entreprise. en fait leur but principal est : lorsque le serveur principal a trop de clients connectes, ils aimeraient avoir un autre serveur identique pour rediriger les autres clients afin d'alleger le premier serveur. donc il faut que les serveurs soient identiques. le load balancing serait plus utilise pour des modules en ruby.

pour repondre a vos questions, non il n'ya pas de dba dans l'entreprise et potentiellement il pourrait y avoir 400 utilisateurs connectes au meme moment.

pour l'instant, l'entreprise a deja achete les 2 autres serveurs donc la solution des 3 serveurs est a l'autre du jour. je viens de faire des recherches, et j'ai trouve le mirroring. cela pourrait etre une solution ?

[SQLpro]

Le mirroring comme le clustering est une solution passive : c'est de la haute dispo, pas du balancing. La base de données clonée est inaccessible tant que le système source n'est pas HS.
400 user c'est un seul serveur c'est peanuts ! J'ai des serveurs avec plus de 5000 user connectés... Là d'ou j'écrit (depusi un de mes clients) le serveur compte plus de 1200 user sans connaître le moindre temps d'attente anormal.
Sachez que fnac.com c'est du SQL server après plusieurs milliers d'utilisateurs connecté.

Le load balancing est concevable pour du serveur web, pas pour un SGBDR !

Oracle fait cela vec RAC, mais avec un cout exorbitant (comptez un minimum de 15 000 $ par CPU sur l'ensemble des machines balancées).
Pour faire cela avec SQL Server vous ne pouvez le faire qu'en asynchrone, par réplication de fusion et en multipliant les licences (Windows + SQL).

Encore une fois votre client fait totalement fausse route !
Quelle est l'architecture globale du système : machine (CPU, RAM, DISQUE), serveur tournant sur machine, nombre attendu d'user, type de transaction...

Lisez l'article que j'ai écrit sur la haute dispo : http://sqlpro.developpez.com/cours/s...disponibilite/

A +

[djraphi23]

En fait j'ai rediscute avec l'entreprise. il n'y aura pas de balancing pour la base de donnees mais pour les scripts Ruby. ca c'est gere avec deux serveurs. sur ces serveurs il y'a aussi une base de donnees. ces bases de donnees ont besoin d'etre synchronisees en temps reel pour qu'elles aient les memes donnees.
etant donne que chaque bdd peut etre modifiee, j'avais pense a la replication par fusion. y'a t'il des solutions plus performantes ?

[zinzineti]

En fait j'ai rediscute avec l'entreprise. il n'y aura pas de balancing pour la base de donnees mais pour les scripts Ruby. ca c'est gere avec deux serveurs. sur ces serveurs il y'a aussi une base de donnees. ces bases de donnees ont besoin d'etre synchronisees en temps reel pour qu'elles aient les memes donnees.
etant donne que chaque bdd peut etre modifiee, j'avais pense a la replication par fusion. y'a t'il des solutions plus performantes ?

La réplication par fusion est consommatrice de ressources,...
La réplication transactionnelle peut être intéressante. Elle est quasi temps réel.
Mais attention, toutes les tables impliquées dans cette réplication doivent avoir une clé primaire.
A+
Etienne ZINZINDOHOUE

[rberthou]

Il serait préférable à mon avis d'isoler le ou les serveurs de base de données des serveurs d'applications. Et j'ai l'impression que dans ta config c'est le même serveur qui abrite les deux.
Cela permet de faire (relativement simplement) le load balancing sur tes serveurs d'applications en conservant une seule base de données.

[djraphi23]

->zinzineti
Oui c'est un problème, ça ne laisse plus beaucoup de ressource pour les applications. A propos, de la réplication transactionnelle, elle peut etre bi-directionnelle (correspondre a mon cas) ? j'ai entendu parler de replication peer to peer, est ce cela ?

->rberthou
C'est ce que je pense également. j'en ai parle mais ils voudraient garder des bases de donnees de secours. au cas ou la bdd crashe.

[rberthou]

->rberthou
C'est ce que je pense également. j'en ai parle mais ils voudraient garder des bases de donnees de secours. au cas ou la bdd crashe.

Cela ne t'empêche pas de faire une synchro de type maitre/esclave qui te permet d'avoir ta base de données de secours.

Par contre SEPARE les serveurs bases de données des serveurs d'applications.

[dbaffaleuf]

Hello,

Je me permets de rajouter qq chose, même si beaucoup de choses ont déjà été dites. Le Peer to peer se rapproche effectivement de ce que tu veux faire, mais il est très difficile à implémenter, car il suppose que les modifications exécutées sur chacune des bases soient partitionnées, pour ne jamais entrer en conflit les unes avec les autres. Par exemple, trois bases une à Paris, une à Londres et une à New-York mettent à jour des stocks par pays (FRA, UK et US). La base en France est accédée en readwrite par les applications FR qui mettent à jour des données françaises, et poussent les modifications sur les bases US et UK, qui font la même chose dans l'autre sens. A aucun moment les mises à jour ne se téléscopent car elles interviennent sur des données différentes. Donc pour mettre en place le P2P, il faut d'abord que l'application soit codée pour.

David B.