Skip to main content

Volver al Índice | Anterior: AlwaysOn: Descripción y configuración | Siguiente: AlwaysOn, Failovers

Utilizando los servidores secundarios en AlwaysOn

Autora: Raquel Vicente de la Rosa

En el capítulo anterior de esta serie, vimos como configurar un grupo de disponibilidad de  AlwaysOn. Con el grupo de alta disponibilidad que creamos en el capítulo anterior, vamos a ver cómo podríamos utilizar el nodo secundario para algunas operaciones de mantenimiento.

Plan de mantenimiento, backups

Si queremos que nuestro plan de mantenimiento que realiza backups se ejecute en el nodo secundario (y por lo tanto no afecte al rendimiento de producción), lo primero que tenemos que hacer es especificar las preferencias de backup. Para ello, si seleccionamos las propiedades del grupo de alta disponibilidad, veremos una pestaña llamada “backup preferences”:

Si seleccionamos “prefer secondary”, y todos los nodos están levantados, se ejecutarán los backups en el secundario. Sin embargo, si el secundario no está disponible, el backup se ejecutará en el primario, para asegurarnos de que tenemos un backup a pesar de todo.

Si en el caso de estar el/los secundario/s caído/s prefiriésemos no tener backup para no afectar al primario podemos seleccionar “Secondary only”.

Estos parámetros decidirán el resultado al ejecutar la función fn_hadr_backup_is_preferred_replica. En este caso, al ejecutarla en el nodo primario:

Y en el secundario:

El siguiente paso es crear un plan de mantenimiento en cada uno de estos nodos. Es necesario crearlo en ambos porque los planes de mantenimiento son objetos a nivel de instancia, y como comentamos en el capítulo anterior, la diferencia principal entre AlwaysOn y una instancia clusterizada es que en AlwaysOn tenemos dos instancias diferentes.

Al crear el plan de mantenimiento, en la tarea de backup tendremos que especificar “copy-only backup”. En caso contrario, tendríamos el error: “The selected backup type is not supported on a ‘Always On Secondary’ replica”. 

La única diferencia entre un backup “copy-only” y un backup “normal” es que no es un punto de inicio para los backups diferenciales. Por lo tanto, si nuestra estrategia de backup no incluye backups diferenciales, esta diferencia no tiene ningún efecto.

Por lo tanto, la tarea de backup dentro del plan de mantenimiento quedaría:

Supongamos que programamos nuestros planes de mantenimiento idénticos en ambos servidores para ejecutarse a las 12 de la noche. ¿Qué pasaría al llegar esta hora?

  • En el servidor primario, el plan de mantenimiento detectaría que no es la réplica preferida (basándose en los resultados de fn_hadr_backup_is_preferred_replica) y no realizaría el backup.
  • En el servidor secundario, el plan de mantenimiento detectaría que sí es la réplica preferida y realizaría el backup.

Si centralizamos la ruta donde se almacenan los backups, tendremos siempre un backup a las 12 de la noche, independientemente de cuál de los dos nodos sea el primario.

Tareas de comprobación, dbcc checkdb

Otra tarea interesante que se puede realizar en el secundario, y por tanto liberar de carga el primario es la comprobación de integridad de la base de datos. Para ello simplemente ejecutaríamos DBCC CHECKDB en el nodo secundario.

Esta funcionalidad es especialmente interesante en servidores muy cargados, ya que la operación de chequeo de integridad consume una gran cantidad de recursos, que realizándose en el secundario no afectaría a nuestro sistema productivo

Microsoft está realizando una encuesta en línea para comprender su opinión del sitio web de. Si decide participar, se le presentará la encuesta en línea cuando abandone el sitio web de.

¿Desea participar?