Always On

Cuando hablamos de Alta Disponibilidad en SQL Server, los Grupos de Disponibilidad Always On suelen ser la opción que se menciona con mayor frecuencia. No es para menos, realmente son la solución de alta disponibilidad más completa que ofrece SQL Server. Sin embargo, existe una idea errónea generalizada: que el modo sincrónico de AlwaysOn garantiza la pérdida cero de datos. A primera vista, esta suposición puede parecer razonable, pero en este artículo explicaré por qué no es necesariamente cierto y analizaremos las implicaciones técnicas detrás de esta afirmación.

El mito de la pérdida cero de datos en Always On

El modo sincrónico en los Grupos de Disponibilidad AlwaysOn está diseñado para garantizar que los datos se escriban en todas las réplicas sincrónicas antes de confirmar una transacción. Esto implica que las transacciones no se considerarán completadas hasta que los datos se escriban tanto en la réplica principal como en las secundarias configuradas en modo sincrónico. A simple vista, parece que este comportamiento elimina cualquier posibilidad de pérdida de datos, pero hay ciertos escenarios en los que esto no es así.

Cómo funciona el Always On en modo síncrono

En el modo síncrono, el proceso sigue estos pasos:

1. El nodo primario recibe una transacción.
2. Los datos de la transacción se envían a todas las réplicas secundarias configuradas en modo sincrónico.
3. Las réplicas secundarias confirman que los datos han sido escritos en su registro de transacciones (log).
4. Solo después de recibir las confirmaciones de todas las réplicas, el nodo primario completa la transacción. Realmente esto se puede ajustar para que no sea necesario esperar a todas las replicas secundarias con la opción REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

Aunque este flujo parece muy robusto, hay ciertas limitaciones y condiciones que pueden comprometer la integridad de los datos.

Excepciones

Todo esto suena muy bonito, precioso diría yo. Y así funciona realmente, excepto cuando algo no va bien. Si la réplica secundaria deja de estar disponible, llámalo reinicio, parcheo o cualquiera de los múltiples otros motivos que puedan surgir dejamos de tener alta disponibilidad. Realmente está contemplado, mirad. Si leemos la documentación nos encontramos con algo que ya no suena tan bien:

«Si la réplica principal y una réplica secundaria determinada se configuran ambas para el modo de confirmación sincrónica, la réplica principal espera a que la réplica secundaria confirme que ha reforzado el registro (a menos que la réplica secundaria no pueda hacer ping a la réplica principal en el período de tiempo de espera de sesión de la principal).
Si el período de tiempo de espera de sesión de la réplica principal es superado por una réplica secundaria, la replicación principal pasa temporalmente al modo de confirmación asincrónica para esa replicación secundaria. Cuando la replicación secundaria vuelva a conectarse con la replicación primaria, se reanuda el modo de confirmación sincrónica.«

En resumidas cuentas, y tiene hasta sentido, si la réplica secundaria no está disponible, por el motivo que sea, las transacciones no se detendrán y seguiremos trabajando con normalidad sobre la réplica principal sin notar nada pero no tendremos alta disponibilidad. Cuando la réplica secundaria nuevamente esté disponible empezará a replicar todas las transacciones pendientes y, un failover, antes de que termine, tendrá pérdida de datos.

Casos prácticos donde puede ocurrir pérdida de datos con Always On

Hemos nombrado ya alguno de los escenarios en los que podríamos tener una pérdida de datos con Always On, pero hay más, estos son los más comunes. 

• Latencia de red alta: Si la red entre las réplicas tiene una latencia significativa, puede aumentar la probabilidad de inconsistencias. En casos extremos, una réplica secundaria podría quedar rezagada y, como dice la documentación, pasar a modo asíncrono hasta que se recupere la normalidad.
• Fallos simultáneos en nodos múltiples: En un entorno de clúster, si tanto el nodo primario como las réplicas sincrónicas fallan al mismo tiempo (por ejemplo, por un corte de energía en el data center), se pueden perder datos que no hayan sido escritos en disco.
• Problemas en el subsistema de almacenamiento: Si el almacenamiento subyacente es compartido para todos los nodos y experimenta corrupción o retrasos significativos, incluso las transacciones confirmadas podrían estar en riesgo.

Prácticas recomendadas en Always On para mitigar riesgos

Si bien sabemos que no es teóricamente imposible la pérdida de datos, también existen una serie de medidas que, como DBAs, podemos tomar para reducir el riesgo. La primera y más eficaz es configurar múltiples réplicas síncronas. Tener más de una réplica puede reducir las probabilidades de pérdida de datos, ya que sería improbable que todas las réplicas fallen simultáneamente. Recuerda que Always On admite un total de 8 réplicas secundarias.

Las siguientes medidas, aunque imprescindibles, no van a tener un impacto tan directo en la reducción del riesgo, simplemente nos permitirán localizar el problema y tomar medidas antes de que sea tarde. Como habrás adivinado ya, estoy hablando de monitorizar la latencia de replicación: Es crucial monitorizar continuamente la latencia entre el nodo primario y las réplicas y tener un buen sistema de alerta para detectar problemas potenciales. También deberemos realizar pruebas regulares de failover: Realizar pruebas regulares ayuda a garantizar que los nodos secundarios estén configurados correctamente y puedan asumir el rol de primario sin perder datos.

Por último, pero no menos importante deberemos tener una solución de respaldo complementaria. Aunque los Grupos de Disponibilidad AlwaysOn son poderosos, una estrategia de copias de seguridad sólida sigue siendo indispensable. No solo para afrontar fallos de la infraestructura, también porque un borrado o actualización incorrecta se replicará inmediatamente por todas las réplicas y las copias de seguridad serán lo único que nos salve.

Conclusión

Los Grupos de Disponibilidad Always On son una solución robusta para alta disponibilidad y recuperación ante desastres. Sin embargo, como hemos visto, el modo sincrónico no es una garantía absoluta de pérdida cero de datos. Comprender estas limitaciones y diseñar una arquitectura con redundancias adicionales es fundamental para minimizar riesgos y garantizar la integridad de los datos. Siempre debemos complementar nuestras configuraciones con monitorización proactiva, pruebas de failover y estrategias de respaldo adecuadas.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

En este artículo vamos a hablar de dos configuraciones importantes para el funcionamiento óptimo de un grupo de disponibilidad AlwaysOn en SQL Server: el session timeout y el health check. Estas configuraciones nos permiten controlar cómo y cuándo se produce un balanceo (failover) automático entre los nodos del grupo, y cómo se determina el estado de salud de cada réplica. Si quieres saber más sobre qué es un AlwaysOn y cómo configurarlo, te recomendamos que leas nuestro artículo sobre ello aquí.

Consideraciones de salud de nuestro AlwaysOn

SQL Server pone a nuestra disposición distintas configuraciones sobre el balanceo de nuestro AlwaysOn. Por un lado podemos definir el tiempo que una transacción puede tardar en replicarse antes de considerar que hay un problema con esa réplica y por otro podremos definir el tiempo que tiene que pasar una réplica en un estado crítico para sacarla del grupo de disponibilidad y balancear o detener la replicación. Además podremos definir varios niveles de criticidad admisibles para considerar este escenario.

¿Qué es el session timeout de AlwaysOn?

El session timeout o tiempo de espera de sesión es el tiempo máximo que una sesión puede estar inactiva antes de que nuestro AlwaysOn determine que esa réplica no está accesible. Esto puede ocurrir cuando hay una interrupción en la comunicación entre el cliente y el servidor, o cuando el servidor está muy ocupado y no puede atender las solicitudes del cliente. Esta propiedad se define por cada réplica y representa el tiempo que puede esperar un ping entre ella misma y el nodo principal del clúster.

El valor por defecto del session timeout para un AlwaysOn es de 10 segundos, pero se puede modificar mediante la propiedad “Connection Timeout” de la cadena de conexión, o mediante la propiedad “SessionTimeout” del grupo de disponibilidad (Availability Group) en PowerShell. El valor mínimo es de 5 segundos, y el máximo es de 65535 segundos. Microsoft no recomienda un tiempo inferior a 10 segundos ya que podríamos sufrir falsos positivos cuando un sistema saturado no devuelva el ping a tiempo. Por otra parte, un tiempo muy alto puede provocarnos errores de inconsistencia de datos ya que aunque la réplica secundaria no esté respondiendo, si estamos dentro de ese umbral definido, SQL no va a actuar como si hubiera un error y va a seguir intentando insertar datos.

¿Qué es el health check de AlwaysOn?

El health check es el proceso por el cual el WSFC comprueba el estado de salud de cada réplica del grupo de disponibilidad. El health check se basa en una serie de criterios que evalúan el rendimiento y la disponibilidad de cada réplica, tales como:

• El tiempo de respuesta del servidor
• El tiempo de recuperación de la base de datos
• El número de errores graves
• El tamaño del registro de transacciones
• El tiempo de sincronización entre las réplicas

Cada criterio tiene un umbral asociado que determina si la réplica está en un estado saludable, advertencia o crítico. Si una réplica primaria pasa a un estado crítico, se produce un failover automático a la réplica secundaria con mayor prioridad. Si una réplica secundaria pasa a un estado crítico, se excluye del grupo de disponibilidad hasta que se recupere.

Mecanismo Is-Alive

Por defecto se hará un chequeo de la salud de las réplicas cada 5 segundos. Sin embargo, el health check tiene un timeout de 15 segundos por defecto. Esto es porque durante ese tiempo se realizan 3 comprobaciones y si no se obtiene una respuesta positiva antes de 3 erróneas se considera a esa réplica en estado crítico. Nosotros, podremos modificar el tiempo máximo de timeout mediante la propiedad “HealthCheckTimeout” del grupo de disponibilidad (Availability Group) en PowerShell. El valor mínimo es de 3 segundos, y el máximo es de 9999 segundos. Durante este tiempo se harán varios chequeos de salud de las réplicas y solo se notificará el error si no se recupera antes del tiempo de espera establecido.

Niveles de error admisibles

Como hemos comentado al principio, WSFC contempla hasta 5 niveles de error que podemos configurar siendo uno el más permisivo y 5 el más “paranoico”. En nuestro caso, nuestro AlwaysOn solo considerará una réplica en fallo si cumple con los criterios del nivel establecido o los de los niveles anteriores. 

1. OnServerDown: El nivel uno de error solo considera una réplica en fallo en caso de caída del sistema operativo. No se comprueba nada más.
2. OnServerUnresponsive: Este segundo nivel, considera un estado crítico en caso de que no se produzca una respuesta al procedimiento de chequeo de salud sp_server_diagnostics.
3. OnCriticalServerError: Este tercer nivel es el por defecto cuando creamos un clúster y considera un estado crítico, además de los dos anteriores, si uno de los componentes del servidor está reportando un error. Por ejemplo un error de sector defectuoso en un disco.
4. OnModerateServerError: Este nivel considera una réplica en estado crítico si uno de los componentes de registro del servidor tiene un error. Por ejemplo varios DUMP de memoria consecutivos.
5. OnAnyQualifiedFailureConitions: Este es el nivel más paranoico y considera una réplica en estado crítico ante cualquier error de SQL Server como podría ser un deadlock. 

Conclusión

En este artículo hemos visto qué son el session timeout y el health check, y cómo influyen en el comportamiento de un grupo de disponibilidad AlwaysOn en SQL Server. Hemos aprendido cómo modificar estas configuraciones según nuestras necesidades, y cómo afectan al failover automático y a la continuidad del servicio. Esperamos que te haya resultado útil e interesante, y te invitamos a que nos sigas leyendo en nuestro blog www.soydba.es, donde encontrarás más artículos sobre SQL Server y otros temas relacionados con la administración de bases de datos.

Espero que este artículo te haya sido útil. Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de LinkedIn y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!