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-rep...
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/