[Linux-HA] "Shutdown delayed until current resource activity
finishes"
Alan Robertson
alanr at unix.sh
Tue Mar 23 12:16:30 MST 2004
ha at freightgate.com wrote:
> Hi,
>
> I am still trying to figure out this mysql setup.
>
> Here is the background once again:
> 2 servers (data1 and data2) running a mysql database (data1 as master and
> data2 as replicating slave).
> They share the same virtual IP using heartbeat.
> In case data1 fails, data2 gets the virtual IP and will be the new active
> database server.
> Since I can not fail back onto data1 automatically (this would screw up the
> master/slave mechanism since the master is now outdated and can not be used
> as such any more), I need to somehow prevent data1 from taking the Ips back
> - no matter what.
>
> So my idea was to just put a service in the haresource file that will do
> what I have to do when the resource comes up or down:
>
> data1.idc.freightgate.com IPaddr::192.168.101.101/24/eth0
> IPaddr::192.168.102.101/24/eth1 mysql_vs
>
>
> "mysql_vs start" will call a "slave stop" on the slave in order to decouple
> the slave db from the master and prevent inconsistencies on the slave once
> the master comes back.
>
> On the master side, I need to prevent heartbeat from taking over the virtual
> IP again until I have manually reversed the old master/slave setup. data1
> has to be manually configured to be a slave of data2, which is now the new
> master. So I was hoping to have "mysql_vs stop" just shut down heartbeat by
> executing a "service heartbeat stop".
> However, when data1 tries to release the resources, it hangs with a
> "Shutdown delayed until current resource activity finishes" log entry. This
> seems to be caused by the "service heartbeat stop" command in the mysql_vs
> service script. Does anybody know why this happens?
>
> How can I automatically shut down heartbeat once it has released resources
> in order to prevent it from re-aquiring the resources at a later time.
> I know that I am risking not having any DB server any more in case data2
> fails as well, but in my case, no data is better than inconsistent and
> unreliable data.
Mysql replication is currently asynchronous - so it's a bit risky to use it
in a failover situation. I'd recommend looking at DRBD - which can be
configured for synchronous replication. Then, you have fewer worries.
--
Alan Robertson <alanr at unix.sh>
"Openness is the foundation and preservative of friendship... Let me claim
from you at all times your undisguised opinions." - William Wilberforce
More information about the Linux-HA
mailing list