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.
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.
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.
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.
Thanks,
Charles
On Thu, Oct 13, 2011 at 2:14 PM, Florian Haas <[email protected]> wrote:
> On 2011-10-13 18:57, Charles Richard wrote:
> > Hi,
> >
> > Have a curiosity question to see if anybody out there is using MySQL with
> > heartbeat or pacemaker on 2 nodes without using DRBD? And if so, is it
> an
> > automatic or a manual failover.
>
> You can use Pacemaker managed MySQL on shared storage, or you can manage
> MySQL Replication from Pacemaker. Both are possible and supported.
>
> > The reason I'm thinking somebody might want to do this is if, as in my
> case,
> > management won't invest in Stonith devices so the DRBD/Pacemaker scheme
> > would work correctly or if the risk of a bad master is too high and
> people
> > simply rely on mysql replication with a manual failover when STONITH
> devices
> > won't be purchased.
>
> If you just wanted manual "failover", you wouldn't be thinking about a
> cluster. And if you were to run on shared storage, you absolutely,
> positively MUST use fencing/STONITH. Did I mention you must? Well, you
> must.
>
> > It seems that using DRBD/Pacemaker without stonith devices would bring a
> > risk of corrupt data which i guess could still be a lesser risk than
> > potentially having a master with bad data and potential bad backups.
>
> I'm not following. What's the difference between "corrupt data" and "bad
> data" in your scheme? And, also, DRBD is not a backup, just as much as
> RAID is not backup. Fat-finger DROP TABLE, boom, it's dropped in both
> replicas. Backup is an issue distinct from storage replication, and an
> issue you'll have to address separately.
>
> Maybe you could start by stating requirements, and then we can make a
> suggestion which HA option suits your use case best.
>
> Cheers,
> Florian
>
> --
> Need help with High Availability?
> http://www.hastexo.com/now
> _______________________________________________
> 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
