List:Replication« Previous MessageNext Message »
From:Rick James Date:March 20 2008 7:30pm
Subject:RE: Basic questions on slave servers
View as plain text  
* Write to only one of the Masters -- this eliminates various
auto-increment issues, etc.  Also, writing to both masters buys nothing,
certainly not write-scalability since all writes have to be performed on
both machines.

* Do not attempt to deploy automatic failover -- there can be partial
network outages that will fool the automatic thingie into thinking a
Master is down.  You can end up with 2 masters being written to; this
will hopelessly corrupt the data.

* If you scale reads by having slaves, some should hang off each Master.
This way, half your slaves are still up-to-date if one (either) master
dies.

* There are rare cases where "one" item in the replication stream
between the Masters will get lost in a hard crash.

* Put your Masters in two geographically separate places -- why have
dual-master if a power failure (earthquake, etc) can still bring down
the whole system?

* To be doubly safe, set the backup master to read_only.

* Replication items will not "loop" -- the server_id of the original
sender is noticed, thereby allowing the items to be tossed.

> -----Original Message-----
> From: Andy Smith [mailto:a.smith@stripped] 
> Sent: Thursday, March 20, 2008 10:52 AM
> To: replication@stripped
> Subject: Re: Basic questions on slave servers
> 
> Hi Martin,
> 
>   ok thanks, so the next questions that come to mind are:
> 
> You say in the past its not been recommended, that implies 
> that the situation has now changed and that
> this is seen as a stable configuration (production ready or 
> however u want to call it). Would that be correct?
> 
> Good to hear your working on some complete documentation! In 
> the mean time, can you point me at any
> useful information regarding this?? How it handles 
> replication WRT writes to multiple hosts etc?
> 
> If I just need HA and in practice I am never going to be 
> doing writes to both masters at the same time is this
> already a fairly robust solution for my needs? Ie perhaps I 
> will have a floating IP which Ill move from one system
> to the other in the event of any issues on the primary master,
> 
> thanks for your help! Andy.
> There are two reasons for this:
> 
> 1) It's not something that in the past we have recommended as a  
> solution because of the potential problems (overwriting IDs, getting  
> DBs out of sync, etc).
> 
> 2) We did have, incomplete, information and advice in the manual,  
> which was removed to be part of a new topology chapter. This new  
> chapter is currently being written :)
> 
Thread
Basic questions on slave serversAndy Smith18 Mar
  • Re: Basic questions on slave serversChris.Leeworthy18 Mar
    • Re: Basic questions on slave serversEd W23 Mar
      • Re: Basic questions on slave serversArthur Fuller23 Mar
        • Re: Basic questions on slave serversEd W23 Mar
  • RE: Basic questions on slave serversEdward F. Pauley II18 Mar
Re: Basic questions on slave serversAndy Smith18 Mar
  • RE: Basic questions on slave serversRick James19 Mar
Re: Basic questions on slave serversAndy Smith20 Mar
  • Re: Basic questions on slave serversMartin MC Brown20 Mar
Re: Basic questions on slave serversAndy Smith20 Mar
  • Re: Basic questions on slave serversMarcus Bointon20 Mar
  • RE: Basic questions on slave serversRick James20 Mar
    • Re: Basic questions on slave serversEric Frazier20 Mar
      • RE: Basic questions on slave serversRick James20 Mar
        • Re: Basic questions on slave serversMoon's Father21 Mar
Re: Basic questions on slave serversAndy Smith21 Mar