Failover en Azure SQL Server

Una de las soluciones para alta disponibilidad de bases de datos con las que contamos en Azure es el auto-failover, el mismo que conocemos en una arquitectura on premise. Failover nos permite configurar dos o más nodos de réplica en nuestras bases de datos críticas.

Puede sonar quizá muy similar la configuración de geo-replicación que ofrece Azure incluso en otros servicios como Azure Data Lake Gen2, pero hay ciertas diferencias marcadas en el funcionamiento de ambos, como:

  1. Failover proporciona un listener para operaciones de lectura y escritura, y uno de solo lectura, los cuales se configuran a nivel de aplicación y no requieren actualización en caso de algún switch por desastres, mantenimiento, o cualquier otro evento que saque de operación al nodo principal.
  2. Es posible crear una configuración de failover utilizando instancias administradas en un IaaS. La geo-replicación aplica para PaaS. Por lo que, si tenemos nodos administrados, la única solución es el auto-failover group.
  3. Cada instancia de failover debe estar en una región distinta; mientras la geo-replicación puede tener dos o más nodos en la misma región
  4. Con failover solo podremos configurar dos nodos (un activo, un pasivo), pero en geo-replicación podremos configurar múltiples nodos (un activo, n pasivos)
  5. La geo-replicación se hace para una única base de datos, mientras que utilizando failover podremos configurarlo para más de una

Configuración de failover en Azure SQL Server

Lo primero que debemos hacer, es crear un “failover group“, para lo que deberemos ubicarnos en el servidor que contiene la base de datos que replicaremos. allí navegaremos a “Settings“>”Failover groups” utilizando el panel izquierdo de Azure.

Daremos clic sobre el botón “+ Add group“. Esto nos abrirá un formulario para la creación del grupo. En él:

  • le daremos un nombre al grupo,
  • configuraremos el servidor secundario en la opción “Secondary server“,
  • configuraremos la política de lectura y escritura en automático para que el failover entre en acción cuando se detecte una indisponibilidad del nodo principal,
  • la opción de “Read/Write grace period (hours)” hace referencia al tiempo de espera antes de colocar en acción el failover para evitar la pérdida de datos que puede generar un failover inmediato, y
  • seleccionaremos la o las bases de datos que queramos replicar.

En la selección del servidor secundario debemos seleccionar uno de los previamente creados en nuestro tenant, y también podremos crear uno nuevo directamente desde esta ventana.

En la opción de “Database within the group” seleccionaremos la base de datos a replicar. Luego daremos clic sobre “Create“. Ahora solo quedará esperar un par de minutos mientras se habilita el grupo de failover y se hace la primera sincronización de la(s) base(s) de datos seleccionada para replicación.

En cuanto se finalice la configuración de la geo-replicación, en la configuración de greo-replicación de nuestra base de datos tendremos una vista similar a esta:

El gráfico anterior representa el estado actual de una base de datos configurada en un auto-failover group. Tenemos el nodo principal (activo) en un Azure SQL Server en “East US“, y el nodo secundario (pasivo) en “Brazil South“.

Switch entre nodos de Azure SQL Server manualmente

Aunque el primer servidor queda como primario, esto puede alterarse manualmente, pasando el secundario a servidor activo, y el primario a pasivo. Para ello simplemente nos dirigimos al servidor principal y damos clic en “Settings“>”Failover groups“, allí seleccionaremos el grupo que alteraremos.

Tendremos la siguiente vista gráfica de nuestra configuración:

En ella se nos indica cual es el nodo principal (en azul) y cuál es el secundario (verde). Para cambiarlo, debemos dar clic sobre el botón “Failover“. Iniciará un proceso de sincronización entre ambos nodos, luego la configuración de cambio de roles entre ambos nodos.

La opción llamada “Forced failover” hará el switch omitiendo la sincronización de cualquier dato faltante, por lo que podrá causar perdida de información.

Si este articulo te fue de utilidad, te invito a leer como ocultar datos sensibles en tus bases de datos, dando clic en este link

You May Also Like