List:Replication« Previous MessageNext Message »
From:Mike Diehl Date:April 7 2010 4:27pm
Subject:Re: Circular replication?
View as plain text  
On Wednesday 07 April 2010 12:56:23 am Marcus Bointon wrote:
> On 7 Apr 2010, at 06:38, Mike Diehl wrote:
> > 1.  Will it work?  If so, is it stable?
> Yes, and in my experience, yes.
> > 2.  What happens when I want to add/remove a host from the circle?
> You need to reset master info for each slave link.

I assume that I only need to update the master information at the point in the 
circle that get's "broken" in order to add/remove the server, right?  Or do 
all of the db servers need to know about the change?

> > 3.  Is there a better way to do it?  I do NOT want a solution where I
> > have to write to one server and read from another.  The defeats my
> > reliability motivation.
> Replication does not buy you performance at all, if anything it reduces it.
> Because of this, a pair of servers in master-master is pretty much optimal.
> Any more doesn't buy you much (unless perhaps one is offsite). You're
> probably better off with 2 masters and a slave. I'd recommend that you use
> mmm to manage it all as that extends the redundancy right to the app level,
> giving you transparent failover - it works really well for me.

Ya, one of the servers is off-site.  I've got twin servers in a co-lo in a 
different state.  These machines have to be up as close to 100% as I can 
afford.  Then I have a local machine here at the office.  Pulling data in 
from the Internet is slow(ish) so I'd like to keep the local machine sync'd 
for LOCAL performance reasons. 

> Splitting reads and writes has nothing to do with reliability - you can
> choose to do so or not regardless of the replication setup so you never
> _have_ to do it, but you might _want_ to. Splitting reads and writes CAN
> buy you performance as you can more or less multiply read performance by
> the number of slaves, however, look into replication latency to be sure
> your app can cope with that (especially the worst case of
> read-what-I-just-wrote).

A split read/write scheme will affect reliability if one of the write servers 
happends to be down...  As I'm understanding it, Mysql's replication would 
survive this scenario.  What I'd be getting is the ability to do local 
reads/writes and Mysql would simply propogate my writes.  For the most part, 
data latency won't be a big deal for my applications unless we're talking 
HOURS. (and we're not, unless something is BAD wrong.)

My research has turned up a package called Mysql Multi Master Manager(?),mmmm.  
My initial reading indicates that this tool won't work across different 
networks, right?

> Marcus


Take care and have fun,
Mike Diehl.
Circular replication?Mike Diehl7 Apr
  • Re: Circular replication?Marcus Bointon7 Apr
    • Re: Circular replication?Mike Diehl7 Apr
      • Re: Circular replication?Marcus Bointon7 Apr
        • Re: Circular replication?Mike Diehl7 Apr
      • Re: Circular replication?Andrew Garner7 Apr
        • Re: Circular replication?Max Schubert7 Apr
          • Re: Circular replication?Mike Diehl7 Apr
            • Re: Circular replication?Max Schubert7 Apr
  • Re: Circular replication?Ben Mildren7 Apr