Hola a todos, recientemente hemos tenido que realizar un failover manual en SQL Server AlwaysOn. Se trataba de una intervención planificada en uno de nuestros clientes. Hoy vamos a contaros en qué consiste, cuándo realizarlo y cómo.
Conceptos básicos
Aunque si no se conoce puede sonar un poco extraño y que da bastante miedo, al ver «fail» en el nombre, realmente no es para tanto siendo controlado. Solo tenemos que tener claros algunos conceptos.
AlwaysOn
Se trata de un sistema de alta disponibilidad para la base de datos SQL Server. Esto de forma muy resumida, implica tener una estructura que permita que la base de datos esté siempre dando servicio, incluso en caso de fallo del servidor principal de base de datos. Para esta estructura necesitamos al menos dos servidores de base de datos.
Supongamos que tenemos dos servidores (uno principal), y otro secundario, disponible para dar servicio en caso de indisponibilidad del principal. En esta estructura el servidor principal envía constantemente los cambios al secundario. En caso de indisponibilidad, el servidor secundario tendría los mismos datos y solo habría unos segundos de corte entre el cambio de un servidor a otro, pero seguiría funcionando todo con normalidad. Sin tener que cambiar la cadena de conexión en las aplicaciones ni realizar ningún cambio. Las aplicaciones se conectan a «un alias», en vez de a un servidor en concreto. Esta es la parte más interesante de este sistema. En caso de fallo, la recuperación, sería en muy pocos segundos.
Failover
Se trata del proceso de cambio de servidor, en caso de indisponibilidad del principal. Queremos hacer un énfasis en indisponibilidad. No tiene por qué ser un fallo del servidor, problemas de red, etc. Puede ser también, la necesidad de hacer el cambio de nodo principal para instalar actualizaciones y parches en el servidor principal, reiniciar, etc.
Se puede usar un failover manual, como fue el que hicimos recientemente y explicaremos el procedimiento en este artículo. O un failover automático, que se produce en caso de indisponibilidad «no planificada» del servidor principal.
En función de cada escenario y cliente, puede convenir configurar AlwaysOn de una otra forma, ya que por ejemplo, no se quiere que se realice el cambio automático de nodo, sin ser chequeado por alguien.
Failover manual
Una vez explicados los conceptos básicos. Os mostraremos cómo realizar un failover manual, entre servidores para un mantenimiento planificado. Desde actualizaciones de sistema operativo, parches de bases de datos, etc. hasta un reinicio programado.
Una vez que tenemos el el entorno en AlwaysOn, accedemos a SSMS, y deberemos acceder al servidor principal, y la sección de AlwaysOn, clicar la opción «Failover» en nuestro grupo de disponibilidad, que aparecerá al desplegar «Availability Groups».
Esto iniciará un asistente, el que llegaremos a una ventana como esta, en la que debemos seleccionar el nuevo servidor principal. Para ello nos mostrará los servidores secundarios. En nuestro caso, solo uno:
En la siguiente pantalla, nos pedirá iniciar sesión en el servidor seleccionado. Tras ello podremos continuar y nos mostrará un resumen con las bases de datos afectadas, así como qué servidor tiene el rol primario ahora, y quién lo tendrá tras el failover.
Finalmente, clicaremos en el botón de «Finish» para iniciar el proceso. Generalmente es muy rápido no demora más de 5-10 segundos, en función del entorno, la red, etc. En caso de querer volver al nodo original, el proceso sería el mismo. Nos conectaríamos al nodo principal actual, seleccionamos el nodo original en el asistente, y todo estaría como estaba inicialmente.
¿Cuándo realizar un failover manual?
Como hemos visto, esta operativa, a diferencia del failover automático, se realiza de manera controlada. Está pensada para cuando necesitamos aplicar algún parche, un reinicio pendiente, etc. Si es tu caso, y necesitas contar con expertos en bases de datos SQL Server, para que realicen este tipo de operativas y puedan reaccionar a posibles problemas, puedes contar con nosotros. Contacta con nosotros sin compromiso y valoramos tu caso.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn