Salut,  
 
J'étais entrain de réfléchir à une méthode de replication mysql dans mon cas. Ma réfléxion porte sur les bénéfices en term de perf de la réplication, sans réfléchir au fait que la réplication permet d'améliorer la sécurité des données, que si un DD crashe on a tjs la bdd etc. Je réfléchis juste à une émulation de "load balancing"
 
Prenons par exemple, un site qui réalise 600 reqs/s ( juste insert/update/delete donc sans compter les select ).
Ce site utilise la réplication réparti sur 3 serveurs par exemple.
 
Si chaque serveur doit avoir en permance la dernière version de toutes les données alors chaque serveur doit se prendre 600 req/s donc chaque serveur est surchargé et donc cette méthode aurait aucun intéret?
 
C'est bien comme ca que ca se passe? C'est à dire que la réplication ne sert à rien, pour augmenter les perfs, quand il y a bcp d'insert/update/delete?
 
merci

c'est pas un backup a temps regulier?
programmé quoi

La réplication te permet d'avoir en permance la meme base de données sur plusieurs serveurs.
Si tu fais un insert sur le serveur A, la réplication envoie cet insert sur le serveur B etc.
 
Donc l'intéret principal c'est que si ton serveur A crashe tu ne perds pas ta base de données vu qu'elle est en intégralité sur le serveur B

c'est plus compliqué que ca, mais en gros c'est ça oui.
 
mais généralement, tu a un nombre invraissemblable de select pour une seule mise à jour de données, donc même dans le cas de 600req/s de mises à jour, tu y gagneras certainement.
 
PS: quand je dis que c'est plus complexe, c'est que chaque donné n'est pas répliquée unitairement, mais par lot. un simple verroux (lock) sur les lignes supprimées/mises à jour suffit. dans le cas d'un insert, je ne sais pas exactement comme cela se produit par contre (lock de la table ?)
 
dès que le serveur se trouve avec des requêtes en attente à cause de ces locks spéciaux, il demande une synchro des données avec les serveurs qui l'ont notifié des lock incriminé.
 
ainsi, avec un load balancing bien paramètré, tu peux avoir de gros mismatchs entre les bases, que tu ne synchronise que régulièrement.
 
mettons que sur un serveur tu lance toutes les recuêtes comptables, tu ne seras pas impacté par les mises à jour des stocks. ainsi, pas besoin de les synchroniser en temps réel.
de la même façon, si sur un autre serveur tu gères les stockes, les tables comptables ne t'importent que très peu.

powa > c'est pour aceboard? Si oui, dans ce cas, je serais de l'avis d'arjuna pour le type de réplication à mettre en oeuvre (désynchronisée). Evidemment, tu ne gagneras rien au niveau de la décharge du serveur à ce niveau (au contraire), mais par contre, si tu acceptes de ne pas avoir un outil de recherche en parfaite synchro avec les post, tu pourrais faire basculer celui-ci vers une base répliquée et décharger ainsi le serveur principal (je suppose que c'est un des traitement les plus lourds).

Pour l'instant le moteur de recherche est juste pour les sujets donc c'est tranquille mais là je suis entrain de finir de le dév complétement et ca va augmenter le nombre d'insert donc j'ai peur que cet émulation de load balancing ne soit pas super intéressante.

En effet, ce n'est pas super intéressant, mais bon, la proportion de requète d'insert/update/modification sur un forum est quand même plus importante que dans d'autres cas de figures, donc les cas classiques de balancing ne s'applique pas spécialement bien.
 
Une aute solution serait de mettre complètement le moteur de recherche sur un autre serveur et ainsi décharger entièrement le serveur principal des insertions dans les tables de recherche.