Rick James wrote:
> * 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.
>
It does indeed buy you something. If your masters are in "geographicly
diverse locations" Take 90ms latency to a webserver vs .2ms over the
course of a few million connections.
> * 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.
>
Little bit of a bold statement. Given your failover script, what caused
the problem exactly? How could you have fixed things to prevent the dual
write? How was a dual write even possible according to your DB scheme?
> * 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.
>
Good advice I think.
> * 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.
>
What about sync_binlog=1 ?
> * Replication items will not "loop" -- the server_id of the original
> sender is noticed, thereby allowing the items to be tossed.
>
No one should think of using autoinc keys in tables unless they want to
run into larger problems as they scale, at least not with MySQL. Having
said that, auto_increment_increment, auto_increment_offset allow
screwed up DBs to still work with master - master. I use those because
those choices are not always mine.
Thanks,
Eric
>
>> -----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 :)
>>
>>
>
>
--
Eric Frazier
Holistis.com
216 Main Street, Suite 312
Bathurst, NB, E2A 1A8
Canada
Phone : +1 506 546 8292 ext 3303
Fax : +1 506 546 8092
