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]
