La conmutación por error automática de DB en c # no funciona cuando el servidor principal se desconecta físicamente

Estoy configurando la conmutación por error automática de DB en C # con SQL Server 2008 y tengo una 'alta seguridad con espejo de conmutación por error automático' usando una configuración de testigo y mi cadena de conexión se ve como

"Server=tcp:DC01; Failover Partner=tcp:DC02; database=dbname; uid=sewebsite;pwd=somerndpwd;Connect Timeout=10;Pooling=True;"

Durante las pruebas, cuando apago el servicio SQL Server en el servidor principal, la conmutación por error automática funciona de maravilla, pero si desconecto el servidor principal (apagando el servidor o matando la tarjeta de red) la conmutación por error automática no funciona y mi El sitio web solo se agota.

Encontré este artículo donde la segunda última publicación sugiere que es porque estamos usando tuberías con nombre que no funciona cuando el principal se desconecta, pero forzamos TCP en nuestra cadena de conexión.

¿Qué me falta para que funcione este failover automático de DB?

Después de trabajar con MS durante una semana, hemos descubierto por qué sucede esto.

Esencialmente, la aplicación no falla porque necesita asegurarse de que la base de datos ha fallado, y la conexión SQL se agota antes de que la conexión haya determinado que la base de datos ha fallado.

El proceso para confirmar que la base de datos ha fallado (con todas las configuraciones de registro tcp predeterminadas) es:

1. intente comunicarse con el director, vea que ya no es el director
2. comuníquese con la conmutación por error para asegurarse de que ha fallado y que ahora es el nuevo director.

Cuando el director está inactivo, esta comunicación tarda unos 21 segundos porque:

1. intenta comunicarte con el director, espera 3 segundos, tiempo de espera
2. intente comunicarse con el director nuevamente, espere 6 segundos, tiempo de espera
3. intente comunicarse con el director nuevamente, espere 12 segundos, tiempo de espera
4. intente comunicarse con el socio de conmutación por error, verifique que haya fallado, por lo que debe fallar en la aplicación.

Entonces, si su conexión sql no está esperando 21 segundos (probablemente más en realidad), entonces se agotará el tiempo de espera antes de que termine este baile y no vaya a fallar en absoluto.

La solución es establecer el tiempo de espera en su cadena de conexión a un valor grande, usamos 60 segundos solo para estar seguros.

Salud

Me pregunto si las condiciones de la conmutación por error automática no se cumplen en el momento de sus pruebas. Específicamente: si la base de datos no está sincronizada con el espejo (verifique el estado de espejo de sys.database_mirroring) en el momento de la falla Y / O si el testigo y el espejo no están conectados en ese momento (prueba a través de pings entre roles participantes).

También podría tener una situación en la que su socio y espejo no están conectados entre sí, pero las bases de datos de socio y espejo todavía están conectadas al testigo de forma independiente. En ese caso, el testigo no ve nada malo (y por lo tanto no hay conmutación por error). Pero mencionó que apagó el servidor, por lo que esto parece menos probable.

¿O está diciendo que la conmutación por error finalmente ocurre pero su reconexión falla? En este caso, el tiempo de detección y conmutación por error varía dependiendo de cómo falló el principal y el tiempo total para recuperar el reflejo db.