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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
