That does clear a few things, thanks! One thing I'm still not clear though is on the stonith front, i thought i saw an article that basically said that only stonith hardware devices are really acceptable as their power source is independant of the server. Our servers do support IPMI but the IPMI lan communication will be cut off if the lan interface goes down so the other node that should be shooting the node is not able to. I might have missed something here but that's the impression i get.
Thanks, Charles On Thu, Oct 13, 2011 at 4:04 PM, Florian Haas <[email protected]>wrote: > On 2011-10-13 19:48, Charles Richard wrote: > > Hi, > > > > The requirement ("ideal" setup) would be to just have 2 nodes where we > avoid > > loss of data and with an automatic failover for a MySQL Database with > > existing code using InnoDB. > > > > The only reason we have been thinking manual failover is if all automatic > > failovers we can come up with don't seem like they will work properly, > then > > the last resort is manual failover which obviously would require more of > our > > time, hence last resort solution. > > Pacemaker does support staggered fencing device priorities, where if one > means of fencing malfunctions, you can still fall back to another one. > It also supports purely manual failover with the funnily named > "meatware" (aka "human intervention") STONITH plugin. And of course you > can combine the two, where you have a hardware fencing device, and fall > back to manual. > > > Since we won't have fencing/stonith implemented because it won't be > invested > > in, I'm left to figure out what our alternatives are. > > Seriously, your servers don't support IPMI/iLO/RSA/DRAC? What kind of > servers are those? > > > I see what you're saying for backup being a different beast altogether > and > > we would be comfortable with the risk imposed in a MySQL replication > scheme > > for the "fat finger" issue. > > It's not an either-or proposition. You can easily combined a (shared > storage or DRBD) master with one (or many) replication slaves. All of > which can be managed either in distinct Pacemaker clusters, or in one > big cluster. > > > I've read about a few people using MySQL replication master-master with > > Heartbeat/Pacemaker and by trying a quick test which obviously wasn't > > comprehensive, it seemed to work better than i expected. I guess I'm > just > > trying to figure out how this scenario would lose data. > > Should be fairly obvious. Imagine your replication slave lagging one > second behind your master, and a plane crashing into the master. That > one second's worth of data is gone, _and the user who kicked off the > write never knows it's gone_, as the transaction had already been > completed at that point. Good luck pulling that stunt with e-commerce data. > > MySQL replication cannot supplant DRBD replication at this point. The > former is asynchronous or semi-synchronous at best, the latter is fully > synchronous and guarantees transaction integrity even across failovers. > They also serve different purposes. Use MySQL replication for scaleout > and leave the HA storage replication capability to DRBD. > > Hope this helps. > > Cheers, > Florian > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
