¿"AlwaysOn" no siempre es "Always On?"

Creamos un clúster de conmutación por error de Windows, luego agregamos dos instancias de SQL Server como nodos de un clúster de conmutación por error de SQL Server.

Configuramos los servidores para usar "Grupos de disponibilidad AlwaysOn" en el Administrador de configuración de SQL.

Para probar una conmutación por error, cargué y ejecuté una consulta larga, luego bajé el nodo activo usando Failover Cluster Manager para detener el servicio de clúster en el nodo activo.

La consulta se interrumpió sin conexión, y el servidor se mostró como no disponible durante unos 20 segundos antes de que el nodo fuera drenado y el nuevo nodo se hiciera cargo.

¿Hice esto mal? ¿Cómo debería haber configurado esto para que hubiera poca o ninguna pérdida de conectividad?

¿AlwaysOn no siempre está encendido?

Tienes un montón de preguntas diferentes aquí.

P: ¿Qué es la cosa "siempre encendida"?

Microsoft usa esa marca (que se escribió sin espacios antes de 2016) para describir dos características diferentes:

• Instancias en clúster de conmutación por error (FCI): lo que su abuelo solía llamar un clúster activo / pasivo
• Grupos de disponibilidad (AG): como la creación de reflejo de la base de datos, pero en algunos casos funciona con grupos de bases de datos (pero no con las bases de datos del sistema)

Use esos términos para describir qué característica específica de Always On está utilizando.

P: En una conmutación por error, ¿estará siempre activada?

Ni las FCI ni los AG están siempre encendidos. Durante una conmutación por error, sus transacciones en ejecución fallarán y los reintentos de conexión pueden fallar durante 5-60 segundos (o más). Depende de usted construir una lógica de reintento elegante en sus aplicaciones, o construir herramientas de capacidad degradadas como lo hace Stack Overflow .

P: ¿Cómo configuro Always On?

Varía dramáticamente según:

• Qué función de AO está utilizando (FCI o AG)
• El número de nodos en el clúster
• Cómo quiere manejar el quórum (votación)
• Ya sea que esté utilizando la conmutación por error automática a través de un oyente o un nombre de computadora virtual

Estas son decisiones importantes que implican mucho trabajo de arquitectura. Para obtener detalles más detallados, incluya los detalles anteriores y podremos brindarle más información sobre cómo configurarlo.

P: ¿No es solo una cuestión de marcar la casilla de Always On?

No

Es posible que esté confundiendo los AG (grupos de disponibilidad) "siempre activados" con los FCI (instancias de clúster de conmutación por error), que dependen de WSFC (clúster de conmutación por error de Windows Server).

Hacer clic en "siempre encendido" no garantiza que ahora tenga una configuración AG. Debe configurar las réplicas asíncrona, de sincronización, de solo lectura / conmutación por error, establecer la prioridad y tomar otras consideraciones, como la aplicación admite esta configuración. Por ejemplo, su aplicación podría usar transacciones MSDTC de bases de datos cruzadas, que no son compatibles y pueden causar daños irrecuperables que requieren una restauración de copia de seguridad.

En este momento, lo que está experimentando es una conmutación por error de FCI. Esto es normal. Esto detiene los servicios en un nodo e inicia los servicios en el otro nodo. Esto funciona en el nivel de INSTANCIA. Se configura una solución AG por base de datos y los servicios se ejecutan en ambos nodos. SQL usa las API de WSFC para mantener los datos sincronizados en las réplicas, y la base de datos falla en esa réplica; tenga en cuenta no la instancia.

Es posible que desee hacer muchas pruebas sobre esto antes de implementarlo en producción.

Mi método preferido para probar una conmutación por error en un AG es simplemente desconectar el primario actual. Simplemente apáguelo, apáguelo desde la consola, desconecte su red, elimine el servicio SQL con una bala de plata, lo que sea. No deberías probarlo desde nada parecido a una GUI porque no es así como funciona el caos.

_{Respuesta wiki comunitaria :}

Este es el comportamiento normal y esperado para un clúster.

Es responsabilidad de la aplicación manejar la desconexión con gracia. Cualquier transacción en vuelo se perderá, ya que solo las transacciones confirmadas se replican entre servidores.