March 25, 2008 at 12:23 am
Comments posted to this topic are about the item Configuring SQL Server 2005 Failover Settings in Windows Server 2003
March 25, 2008 at 5:32 am
The article can be a base for further research work. Otherwise it is good. 🙂
March 25, 2008 at 11:40 am
A follow-on article discussing the networking config (heartbeat, public), would be ideal. Sometimes this configuration can cause a fail-over unexpectedly. I've got that t-shirt.
K. Brian Kelley
@kbriankelley
March 26, 2008 at 9:37 am
I agree follow-on article(s) should be added.
As to the unexpected fail-over, it may indicate that there is a problem/situation in the cluster causing the is-alive check giving false alarm. Usually there could be a problem with the private (team) heart-beat, or the system was in a heavy load, which timed out the is-alive connections during the time span specified. And obviously event logs and the cluster log should be examined for further findings. The automatic failover configuration itself doesn't cause the problem but is a reaction to the is-alive's result. And as a result, the failover was unexpected because of the false alarm. This is a bad example for choosing the automatic failover option. In this case, either resolve the false alarm issue, or disable the automatic fail-over option should be done. This article simply laid out different options and the expecting behaviors along the triggering flow to help people design a proper failover scheme to fit their own needs.
March 27, 2008 at 3:31 pm
Richard Lu (3/26/2008)
I agree follow-on article(s) should be added.As to the unexpected fail-over, it may indicate that there is a problem/situation in the cluster causing the is-alive check giving false alarm. Usually there could be a problem with the private (team) heart-beat, or the system was in a heavy load, which timed out the is-alive connections during the time span specified. And obviously event logs and the cluster log should be examined for further findings. The automatic failover configuration itself doesn't cause the problem but is a reaction to the is-alive's result. And as a result, the failover was unexpected because of the false alarm. This is a bad example for choosing the automatic failover option. In this case, either resolve the false alarm issue, or disable the automatic fail-over option should be done. This article simply laid out different options and the expecting behaviors along the triggering flow to help people design a proper failover scheme to fit their own needs.
Exactly. We're on the same wavelength on this one. Going through these possibilities and explaining what's up and why they trigger the fail-over is something I find myself spending a lot of time discussing with folks I'm bringing up to speed on clustering. Good articles in this area would help a lot. 🙂
K. Brian Kelley
@kbriankelley
April 29, 2008 at 10:34 am
Good article Richard. Thanks!
James C.
-----
James Cornell
Kainell Database Specialists
http://www.kainell.com
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply