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/

Oui et non je ne connais pas vos requêtes et d'ou elle viennent, mais a moins qu'elles soient toutes "super super super bien écrite " cela va locker les tables et donc le master va attendre avant décrire les bin log, donc passer les infos au Slave , donc retard

faites un mysql VOTRE DATABASE -e "SHOW INNODB STATUS\G" | grep -i lock

voila ce que j'ai chez moi

Last time write locked in file buf0buf.c line 1693 LATEST DETECTED DEADLOCK mysql tables in use 3, locked 1 LOCK WAIT 7 lock struct(s), heap size 1216 *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 1378305 n bits 312 index `PRIMARY` of table `planning` trx id 0 2820980858 lock mode S locks rec but not gap waiting Record lock, heap no 79 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 mysql tables in use 4, locked 4 1915 lock struct(s), heap size 227312, undo log entries 5 *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 0 page no 1378305 n bits 312 index `PRIMARY` of table `planning` trx id 0 2820980859 lock_mode X locks rec but not gap Record lock, heap no 79 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 Record lock, heap no 133 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 0 page no 1378304 n bits 312 index `PRIMARY` of table `droits_planning` trx id 0 2820980859 lock_mode X locks rec but not gap waiting Record lock, heap no 26 PHYSICAL RECORD: n_fields 10; compact format; info bits 0 Total number of lock structs in row lock hash table 0 mysql tables in use 5, locked 0 mysql tables in use 4, locked 0

pour ralentir mon slave, super simple, je lock une table importante de ma base ( avec simple mysqldump d'une table )

il faut aussi regarder le nombre de requêtes dans le moteur par rapport au nombre de coeurs cpus, dispo sur le serveur chez moi je dois pas dépasser 8 sinon ça commence a ramer, l'escalve prend du retard

ROW OPERATIONS -------------- 3 queries inside InnoDB, 0 queries in queue 6 read views open inside InnoDB Main thread process no. 11669, id 1157658944, state: sleeping Number of rows inserted 102944443, updated 762728, deleted 264058, read 588720012458 0.06 inserts/s, 0.24 updates/s, 0.00 deletes/s, 27425.09 reads/s

voila j'espère que cela vous aidera bye Hugues

Le 17/03/2011 12:54, Greg a écrit :

Le 17/03/2011 12:39, hugues Max a écrit :

...

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 ?

Non, parce que sur le master les écritures sont parallélisés, alors qu'elles sont exécutées séquentiellement par l'unique thread de réplication... Si on rajoute en plus des triggers sur ce flux, tout étant séquentiel, vous voyez où est l'engorgement...