Configuring SQL Server 2005 Failover Settings in Windows Server 2003

  • Richard Lu-422582

    SSC-Addicted

    Points: 417

    Comments posted to this topic are about the item Configuring SQL Server 2005 Failover Settings in Windows Server 2003

  • Anipaul

    SSC-Insane

    Points: 24681

    The article can be a base for further research work. Otherwise it is good. 🙂

  • K. Brian Kelley

    SSC Guru

    Points: 114486

    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

  • Richard Lu-422582

    SSC-Addicted

    Points: 417

    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.

  • K. Brian Kelley

    SSC Guru

    Points: 114486

    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

  • James Cornell-521376

    Valued Member

    Points: 68

    Good article Richard. Thanks!

    James C.

    -----
    James Cornell
    Kainell Database Specialists
    http://www.kainell.com

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply