> You should consider a setup where your website connects to a > master DB and performs any queries it needs to do there. That DB > is replicated to another DB on another machine using a > replication daemon. Replication takes place every (few) second(s) > by the replication daemon. > From the webserver, monitor the database server. If you notice > database connection errors or the number of queued queries > suddenly jumping you know something is up with the database. At > that point, you know you want to switch to the secondary database. > > Take an exclusive lock, wait 10 seconds just to be sure and > change the application / server variables that contain the > datasource information to point to the second database server.
Hah, back to square one! :) This is *precisely* what I did last time, very funny. This gives me some things to think about, then. I guess I'd do well to just modularize my old survey's DB failover code and get it into my survey framework. Thanks also for providing the limitations of the MySQL cluster... I do think those points will prove too restrictive. Thanks again, Jamie ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:203075 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
