List:Replication« Previous MessageNext Message »
From:Manuel Arostegui Date:January 10 2013 9:33am
Subject:Re: Replicating on multiple Slaves DB from one Master
View as plain text  
2013/1/8 shayne.alone@stripped <shayne.alone@stripped>

> Dear Rick;
> thanks for you reply.
> I will try to explain what I did before, depend on your idea:
>
> I use xfs as file system to maximize the I/O performance on disk
> Disk are hardware raided with BBCW
> 2x 600GB (RAID 1) 15K
> ** operation system
> ** ralay logs
> 6x 300GB (RAID 10) 15K
> ** Mysql DATA (ibdata and tables data)
>
> I had been enabled file_per_table and partitioned the large tables to
> lookup faster
> innodb_flush_log_at_trx_commit = 0   ( to not to commit per transaction )
> innodb_flush_support_xa = 0  ( to not to sync file system and log files per
> transaction )
> innodb_flush_method =O_DSYNC ( to import disk utilization )
> and enabled the Large File large-pages
> cat /proc/meminfo | grep -i huge
> AnonHugePages:   6326272 kB
> HugePages_Total:   61440
> HugePages_Free:    59727
> HugePages_Rsvd:    51106
> HugePages_Surp:        0
> Hugepagesize:       2048 kB
> and set the innodb buffer pool to 100GB ( which is using huge block is
> memory as mentioned above)
>
> write now when I start the replication, disk utilization is finally some
> about %30
> and just one of the 24Cores are under the load of about (70% :-S && I don't
> know why it dose not read 100% load ( this core seem to be in use with SQL
> thread   )
> cos I have just one DB to be replication ( totally about 800GB ) the new
> multi thread capability dose not changed any things for me.
>
>
> regard to what I explained:
> Plan A is Done
> Plan B is Done
> Plan C is in progress
>   ** but I didn't still split tables is septate DB ( software team
> challenges :-) )
> Pan D this is what I am reading some about yesterday and like to test
>
>

Hello,

From my point of view, the best long-term solution here is just to split
the cluster and partition the tables to spread them across both clusters.
So you have a bunch tables being written/read from cluster A and the other
half from cluster B.

Upgrading HW will only delay the problem. As soon as you start growing you
will face the same problem (if it is really IO problem and if it's really
that your slaves cannot cope with the load).
I do understand that splitting a cluster might not be easy if you're
backend isn't ready to do so, but it is probably the optimization you can
work on. I also do concede that splitting a cluster costs money/HW as you
need to double your infrastructure.

Cheers
Manuel.

Thread
Replicating on multiple Slaves DB from one Mastershayne.alone@gmail.com7 Jan
  • RE: Replicating on multiple Slaves DB from one MasterRick James7 Jan
    • Re: Replicating on multiple Slaves DB from one Mastershayne.alone@gmail.com8 Jan
      • Re: Replicating on multiple Slaves DB from one MasterAlex Yurchenko8 Jan
        • Re: Replicating on multiple Slaves DB from one Mastershayne.alone@gmail.com8 Jan
          • RE: Replicating on multiple Slaves DB from one MasterRick James8 Jan
      • Re: Replicating on multiple Slaves DB from one MasterManuel Arostegui10 Jan
    • Re: Replicating on multiple Slaves DB from one MasterSimon J Mudd10 Jan