Bonjour
les seules choses qui ralentissent un escale mysql sont les
update/insert sur le Master
quel est votre taux d'INSERT/UPDATE sur SELECT sur le Master ?
avez vous essayé de mettre les fichiers temporaire en tmpfs ? ( nous ont
a monté une partition de 1Go de Ram pour cela sur 16Go)
Hugues.
Le 17/03/2011 12:25, Pierre-Henry Muller a écrit :
Salut,
C'est intéressant mais je connaissais pas donc pas de retour.
Par contre ca promet ce genre de montage.
A suivre
Le 16 mars 2011 à 14:56, Greg a écrit :
Bonjour,
J'aimerai avoir des retours sur Tungsten Replicator si vous en avez :
http://www.continuent.com/solutions/tungsten-replicator
Ce système se substitue au système de réplication natif du SGBDR, et permet de
faire des choses sympas :
- répliquer from MySQL to PostgreSQL
- faire de la réplication en parallèle :
http://scale-out-blog.blogspot.com/2010/10/parallel-replication-on-mysql-report.html
Mon problème, si en plus vous avez une solution : le serveur MySQL A réplique
depuis 4 masters MySQL via un script Perl maison (sources dispo), le serveur B
réplique depuis A via la réplique MySQL standard (Statement based), et contient
des tas de triggers pour transformer / consolider les données.
Mais on a atteint le max de triggers, et le serveur B se maintient entre 0 et
15000 secondes de délais de réplication sur la journée, il n'a pas de délais
que pendant moins de 2h dans une journée... Changer de serveur n'apporterait
pas beaucoup d'améliorations: il faut paralléliser.
Merci :)
--
Greg
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
--
Pierre-Henry Muller
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
