* 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 :)
>
