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:
- El nodo primario recibe una transacción.
- Los datos de la transacción se envían a todas las réplicas secundarias configuradas en modo sincrónico.
- Las réplicas secundarias confirman que los datos han sido escritos en su registro de transacciones (log).
- 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!
