Is the system read-heavy or write-heavy?

Cheers,

Andrew

-----Original Message-----
From: Don MacAskill [mailto:[EMAIL PROTECTED] 
Sent: Monday 06 October 2003 20:47
To: [EMAIL PROTECTED]
Subject: [Fwd: MySQL w/dual-master replication?]



Hey all,

I sent this a few days ago, but it may have gotten lost in the weekend 
for many of you.  Don't worry, I won't keep re-posting it.  :)

I'm hoping someone out there is doing some sort of high-availability 
replication and can give me a few pointers.

Thanks in advance!

Don


-------- Original Message --------
Subject: MySQL w/dual-master replication?
Date: Sat, 04 Oct 2003 11:07:43 -0700
From: Don MacAskill <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]


Hi there,

I realize it's not supported, but nonetheless, I need to investigate how
possible it is.  The primary goal is high-availability, not performance
scaling.

It sounds like if I'm careful, it might work out ok.  Careful means:

- No auto_increment columns... handle unique key assignment in my app

- Update/insert/delete on primary master only except in case of failure

- Prevent possibly 'flap' by automatically using secondary master
exclusively after primary master failure.  Bring up primary master manually
and manually tell the app when to start using it again after it's allowed to
catch back up.

Are there any other gotchas I need to worry about?  Is anyone actually doing
this in a production environment?  I'd love to hear from you.


Another option is to use master/slave, and have a monitoring app change the
slave's status to master after the master has died.  There's info about this
in the FAQ (http://www.mysql.com/doc/en/Replication_FAQ.html), but I'm
afraid the documentation on the sequence of events is pretty vague.  Does
anyone have any insight as to exactly how it works?

In particular, one part of the doc says to use 'STOP SLAVE; RESET MASTER;
CHANGE MASTER TO' and another part of the doc says 'STOP SLAVE;
  CHANGE MASTER TO' ...  which is appropriate?   Certainly, I understand
why 'STOP SLAVE', but why 'RESET MASTER'?   Would the sequence of events
differ if we're just dealing with 1 master/1 slave instead of 1
master/multiple slaves?

Once the old master joins back up, I can let it be a slave for awhile to
catch back up, then swap back, correct?

Thanks in advance!

Don MacAskill
http://onethumb.smugmug.com/





-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:    http://lists.mysql.com/[EMAIL PROTECTED]

Reply via email to