[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