List:Replication« Previous MessageNext Message »
From:Wagner Bianchi Date:September 21 2011 6:39pm
Subject:Re: confirm subscribe to replication@lists.mysql.com
View as plain text  
Hi Ricardo,

I have been configuring this kind of MySQL replication on many customers and
haven't found yet any problem to maintain it. Actually, when you have a
MASTER => SLAVE topology, the unique effort of replication is done by the
SLAVE server, who will catching up on all new events (that modifies data) on
MASTER's binary log. Besides it, there are two threads in SLAVE server that
will 1-) communicates with MASTER in order to retrieve new alterations and
2-) a SQL thread who will execute this alterations locally.

Summarizing, SLAVE will do all replication heavy service while MASTER is a
kind of agnostic server in asynchronous replication. The really good thing
to do when you have scale-out servers is to try to read data from the SLAVE
server and write data on MASTER server.

A good solution could be to use a MASTER <=> MASTER topology, using MySQL
5.1 or 5.5, in order to split writes between servers, operation will
decrease a little more your workload. But, I used to say it: before
scale-out databases, check what your app is doing wrong and fix it.

This is my 2 cents...see you.

Best wishes,
--
Wagner Bianchi



2011/9/21 Ricardo Freitas <ricardo@stripped>

> Hello my good friends!
>
> Recently join the group in hope of getting (and providing) some help.
>
> I already have configured and manage a replication system with a master and
> a slave unit.
>
> Understood most of the process and read a lot about it - had to cause the
> system crashed :)
>
> Since I have a lot of traffic on this particular database, mostly on a
> specific timeframe of one hour everyday with values along the 5500 records
> per minute, I was wondering what implications, performance wise, does a
> master-slave replication system have.
>
> The master would have to not only insert the records but update the binlog
> as well - I'm sure these are microseconds we are talking about but I
> thought
> of asking you guys if someone has already tested this.
>
> Would you guys feel it would make an huge difference to have the db to act
> as master opposed to act as a "single" db ?
>
>
> As long as I'm here, let me ask you a few more questions. To have a
> somewhat
> non-failing database system, what would you guys recommend? I need to have
> a
> realtime solution (the dump backup would not work has it takes too long) -
> I
> thought of the master-slave system cause if somehow the master stops
> working, I can redirect all access (web, etc) to the slave and things would
> flow normally (as far as the user is concerned - I would probably be
> running
> in circles shouting!)
>
> Thanks guys!
>
> Ricardo
>
>
> --
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe:
> http://lists.mysql.com/replication?unsub=1
>
>

Thread
RE: confirm subscribe to replication@lists.mysql.comRicardo Freitas21 Sep
  • Re: confirm subscribe to replication@lists.mysql.comWagner Bianchi21 Sep
    • Re: confirm subscribe to replication@lists.mysql.comMarcus Bointon21 Sep
      • Re: confirm subscribe to replication@lists.mysql.comRicardo21 Sep
        • Re: confirm subscribe to replication@lists.mysql.comWagner Bianchi21 Sep
        • Re: confirm subscribe to replication@lists.mysql.comMarcus Bointon21 Sep
          • Re: confirm subscribe to replication@lists.mysql.comRicardo21 Sep
            • Re: confirm subscribe to replication@lists.mysql.comPrabhat Kumar21 Sep
            • Re: confirm subscribe to replication@lists.mysql.comMarcus Bointon21 Sep
              • Re: confirm subscribe to replication@lists.mysql.comRicardo21 Sep
                • Re: confirm subscribe to replication@lists.mysql.comMarcus Bointon21 Sep
                  • Re: confirm subscribe to replication@lists.mysql.comRicardo22 Sep
      • Re: confirm subscribe to replication@lists.mysql.comWagner Bianchi21 Sep
  • Re: confirm subscribe to replication@lists.mysql.comRick James21 Sep