|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() jerome Inscription : mars 2011 Messages : 4 ![]() |
Bonjour a tous,
J'ai mis en place un maître et un esclave sur une grosse base de données contenant environ 1Milion de lignes. Le fonctionnement est simple, un serveur JBoss qui échange beaucoup avec la BDD (INSERT,DELETE,UPDATE) afin de la mettre à jour et une application web qui interroge celle-ci (SELECT) ainsi que des administrateurs. J'ai tout configuré pour que la relation entre JBoss et la BDD soit faite avec le maître et les relations de lecture (application Web et admin) soit faite avec l'esclave pour permettre aux administrateurs d'effectuer des tests sur la BDD sans attendre pendant 1min. Le problème est que j'ai lancé un script Perl de test sur le maître qui fait un UPDATE sur l'ensemble des entités de la table et en parallèle j'ai fait un SELECT sur la table esclave. Je remarque que la configuration en sert a rien puisque le maître copie instantanément les données sur l'esclave qui effectuer les mêmes requêtes pour mettre à jour sa BDD. Par conséquent ma requête SELECT sur le serveur ESCLAVE est coincé par la surcharge du serveur. Quelle est la solution ? Faut-il retarder la copie des données entre le maître et l'esclave afin de pouvoir interrogé l'esclave pendant la mis à jour du maître ? Je ne vois pas comment il est possible de repartir la charge avec cette méthode que j'ai bien implémentée ? Merci de votre aide et bonne journée |
|
|
00
|
|
|
#2 |
|
Membre du Club
![]() Inscription : mars 2005 Messages : 66 ![]() |
Bonjour,
vous pouvez essayer de paramétrer votre réplication en mode "row-based replication", plutôt que "statement-based replication" Comme c'est de la réplication par ligne, ca devrait moins locker l'esclave, plutôt que de rejouer l'update entier sur l'esclave. # Fewer row locks are required on the master, which thus achieves higher concurrency, for the following types of statements: Fewer row locks are required on the slave for any INSERT, UPDATE, or DELETE statement. Pour cela il faut modifier le paramètre du master: SET GLOBAL binlog_format = 'ROW'; ou le changer dans le my.cnf Sebastien
__________________
DBA SQLServer, Oracle, Mysql, DB2, Postgresql |
|
|
00
|
|
|
#3 |
|
Invité de passage
![]() jerome Inscription : mars 2011 Messages : 4 ![]() |
Bonjour,
Merci pour ton aide slefevre01, je vais essayé sa tout de suite est effectué des test. Cependant je me demande si la réplication est utile pour améliorer les performances avec des besoins de 50% voir 60% écriture et 50% lecture. En effet j'ai vu que la réplication améliore les performances plutot pour des applications avec des besoins 90%lecture et 10% écriture. Quelqu'un aurait des idées autre que la réplication pour améliorer les performances (vues, triggers, partitionnement) ? Merci de votre aide et bonne journée. |
|
|
00
|
|
|
#4 |
|
Invité de passage
![]() jerome Inscription : mars 2011 Messages : 4 ![]() |
Voila je viens de finir les tests avec ta solution slefevre01, mais seulement une amélioration de 5min sur un update de 1h qui ne m’intéresse donc pas tellement.
Je me trouve donc complètement bloqué et ne sais comment faire après avoir parcouru une multitude d'articles et des recherches Google. J'attends et vos réponses et continue de nombreux tests. merci de votre aide |
|
|
00
|
|
|
#5 |
|
Membre du Club
![]() Inscription : mars 2005 Messages : 66 ![]() |
Bonjour,
Un batch d'update d'1h ne doit pas tourner en journée. Ne pas mélanger batch et oltp en journée. Effectivement, suivant votre traitement, les triggers peuvent être une solution (update au fil de l'eau plutôt qu'update massif). Cdlt, Sébastien
__________________
DBA SQLServer, Oracle, Mysql, DB2, Postgresql |
|
|
00
|
|
|
#6 |
|
Invité de passage
![]() jerome Inscription : mars 2011 Messages : 4 ![]() |
Mais il est obligé de tourner durant la journée puisque la BDD est "update" tout au long de la journée et même le soir avec des scripts qui tournent en background.
C'est pour cela que je me demande si l'utilisation de triggers pourra résoudre cela !! Plutôt la partitionnement non ? |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com