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 +