Hi
When the connectivity is lost at both IP and SAN level to the other node, a
failover occurs.
If the server that is running the instance takes too long to respond to a is
alive.
Clustering does not care about a bad application that is bleeding RAM, as
long as the server responds to is alives, it stays in the cluster.
If the application is cluster compliant, then clustering services can manage
it, otherwise clustering just cares that the server is up. Clustering
compliance involves WMI and other API requirements from the application.
MSDN has the information on it.
SQL Server is cluster compliant.
Regards
--------------------------------
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@epprecht.net
MVP Program:
http://www.microsoft.com/mvp Blog:
http://www.msmvps.com/epprecht/ [quoted text, click to view] "tjhazel" <tjhazel@discussions.microsoft.com> wrote in message
news:9F117956-5EC6-4392-8556-E5ECA36A6CE2@microsoft.com...
> What causes SQL Server to fail from the active node other than the
> heartbeat
> flat-lining? I have the cluster installed and tested the heartbeat by
> unplugging the active machine. Failover works great.
>
> My question is what else can cause the failover? Lets say we have a
> memory
> leak. Is there a point when the heartbeat is still fine, but the memory
> is
> slowly being consumed. Is there a threshold that causes a failover?
>
> What about an application that is hung and consuming excessive cpu cycles.
> Assuming the heartbeat is still alive, is there a point when the active
> node
> will fail over?
>
> Is there a good white paper or kb article that can help shed some light on
> this question?
>
> Thanks,
> John