List:General Discussion« Previous MessageNext Message »
From:Jeff Date:September 21 2005 12:23pm
Subject:RE: Circular Replication
View as plain text  
> -----Original Message-----
> From: Bruce Dembecki [mailto:bruce@stripped] 
> Sent: Tuesday, September 20, 2005 23:05
> To: Jeff
> Cc: mysql@stripped
> Subject: Re: Circular Replication
> 
> 
> On Sep 16, 2005, at 11:07 AM, Jeff wrote:
> 
> > There shouldn't be a problem if:
> >
> > server A is ver 4.0.x
> > server B is ver 4.1.x
> >
> > should there?
> >
> 
> There will totally by a problem here... The 4.1 server will take the  
> 4.0 feed without issue. The 4.1 server however puts all sorts of  
> information into the binary log which isn't in the original query,  
> like what sort of collation to use, and which character set it uses  
> and so on... 4.0 doesn't understand such commands and lots of things  
> break in this situation.
> 
> As a side note we deploy servers in pairs, with circular 
> replication.  
> We did three and four server circles, but it gets messy if  
> replication stops somewhere, the data becomes unpredictably  
> inconsistent (assuming all the servers in the circle are getting  
> production updates). Now we do simple two way replication between a  
> pair, and we hang a third server off the pair somewhere just  
> reading... the third server we use for backups, data dumps, reports  
> and other non production issues. Essentially it is something like A<- 
>  >B->C, where A and B have two way replication and C is used for  
> backups/reports etc... anything that changes the data happens 
> on A or B.
> 

I assume you then need to start server B with "--Log_slave_updates"?

> We do some other black magic to manage the replication on C so it's  
> perpetually behind the master servers by between 15 minutes and 2  
> hours... that way if we have a stupid operator error or some other  
> data corrupting event we can stop replication on the backup server  
> before it executes and start from there rather than having to 
> go back  
> to yesterdays backup or something.
> 
> Best Regards, Bruce
> 

Bruce,

Thanks for the info.  All my downstream servers are 4.1 and my masters
are all 4.0.  They will all be brought up to the latest when I can
figure out a production schedule that will allow it.

So for now what I'll have is:

A <-> B -> C
	|\ 
	D E

Where A and B (4.0.16) are masters in a circular replication and C,D,E
(4.1.13) are backups and other read only slave servers .

The reason for needing the circular replication is we are moving our
production systems to another data center and I need to be able to
quickly switch the applications over to the new data center and then
back again if something goes south.

After that however I think I'll keep the two db servers at the new data
center in a circular replication for redundancy probably.

I am interested in how you go about doing a "delayed replication" to
protect against operator error.  We've already fallen victim to that
situation here.

Thanks,

Jeff


Thread
Circular ReplicationJeff16 Sep
  • Re: Circular ReplicationDan Nelson16 Sep
    • RE: Circular ReplicationJeff16 Sep
      • Re: Circular ReplicationDevananda16 Sep
  • Re: Circular ReplicationStefan Kuhn16 Sep
    • Re: Circular ReplicationRaphaĆ«l 'SurcouF' Bordet27 Oct
      • Re: Circular ReplicationStefan Kuhn27 Oct
        • Re: Circular ReplicationJigal van Hemert27 Oct
          • Re: Circular ReplicationDevananda28 Oct
RE: Circular ReplicationJeff McKeon16 Sep
  • RE: Circular ReplicationJeff16 Sep
    • Re: Circular ReplicationDevananda16 Sep
      • Re: Circular ReplicationSid Lane19 Sep
        • Re: Circular ReplicationAlec.Cawley19 Sep
          • Re: Circular ReplicationSid Lane19 Sep
          • RE: Circular ReplicationJeff20 Sep
            • Re: Circular ReplicationDevananda20 Sep
    • Re: Circular ReplicationBruce Dembecki21 Sep
RE: Circular ReplicationJeff20 Sep
RE: Circular ReplicationJeff21 Sep
  • Re: Circular ReplicationBruce Dembecki22 Sep
    • Re: Circular ReplicationHank26 Sep
      • Re: Circular ReplicationHank26 Sep