Volver al Índice | Anterior: Utilizando los servidores secundarios en AlwaysOn | Siguiente: Database recovery advisor
AlwaysOn, Failovers
Autora: Raquel Vicente de la Rosa
En este artículo, vamos a ver varios tipos de failovers. El primero de ellos sería el failover automático cuando uno de los nodos deja de estar operativo.
En nuestro caso particular vamos a apagar el nodo primario inesperadamente. Si abrimos el monitor en el secundario justo antes del fallo (botón derecho sobre AlwaysOn High Availability, show dashboard), veremos:
.png)
Al provocarse el fallo, sin hacerse ninguna acción adicional, veremos:
.png)
Como podemos observar, el secundario ha pasado a ser primario y el nodo desconectado nos aparece con error.
¿Qué habría pasado con nuestra aplicación? Durante el escaso tiempo del failover, habría recibido errores de conexión a la base de datos, pero una vez terminado el failover la aplicación continuaría trabajando sin haber sido necesario realizar ningún cambio en ella. El efecto sería similar al de un corte momentáneo en la red.
Hay que tener en cuenta que el tiempo de failover es considerablemente menor que en el caso de un clúster, ya que la instancia de SQL ya se encuentra iniciada, y sólo es necesario cambiar el estado de la base de datos de “Synchronizing” (similar a “En recuperación”) a “Online”.
El siguiente tipo de failover sería el manual. Imaginemos que nuestro nodo AON1 vuelve a estar disponible. Una vez que hayan pasado unos minutos para volver a estar en estado sincronizado, tendremos la siguiente situación:
.png)
Si iniciamos el failover manual (Start Failover Wizard en la parte de arriba derecha del monitor), después de la pantalla de bienvenida tendremos una pantalla que nos permite elegir el nodo que querremos que empiece a actuar como primario:
En la siguiente pantalla nos pedirá credenciales para conectarnos al nodo remoto:
.png)
Y si continuamos con el asistente, el failover se completa.
El último tipo de failover que tendríamos es un failover manual forzado. Este método se utiliza cuando el estado inicial no es con ambas bases de datos sincronizadas, bien porque estemos en modo asíncrono o porque haya habido algún problema en la sincronización.
El método para realizarlo es similar al manual. La diferencia principal radica en que el sistema no garantiza la no pérdida de datos, porque no se parte de una situación inicial sincronizada. Este método no es recomendable salvo en situaciones de recuperación de desastres en las que esta opción sea la que menos pérdida de datos implica.