Configurando Log Shipping

Log Shipping es una de las formas más rudimentarias de “alta disponibilidad” y recuperación de desastres. Creo que apareció por primera vez en la versión 2000 y que versión tras versión se ha ido mejorando.
Esta configuración consta de tres etapas:

  1. Respaldo del log de transacciones de la instancia primaria
  2. Copia del log de transacciones desde la instancia primaria hacia la segunda instancia
  3. Restauración de las transacciones en la instancia secundaria

Para configurar Log Shipping se necesita

  1. Una instancia primaria con una base de datos con Full Recovery Mode o Bulk-Logged Recovery Mode.
  2. Una instancia secundaria. Esta puede estar en la misma máquina o en otra máquina.
  3. Ambos servicios de SQL Agent deben estar funcionando y con una cuenta de dominio.
  4. Una carpeta donde la cuenta de dominio de SQL Agent pueda leer y escribir.
  5. Solo si ambas instancias están en servidores separados, el servidor primario debe tener la carpeta compartida donde dejará los logs y el servidor secundario debe tener una carpeta donde la cuenta de SQL Agent pueda escribir y leer.
  6. Una tercera instancia para que sea de testigo (Opcional)

Pasos:

1.- Servicios en marcha
Antes de partir, es necesario revisar que el servicio de SQL Agent se encuentra funcionando en ambos servidores (En este caso utilizaré dos máquinas para configurar Log Shipping). Este servicio debe estar configurado con una cuenta de dominio.

2.- Carpetas
En la máquina primaria, crearemos una carpeta compartida donde la cuenta de SQL Agent tenga permisos de lectura y escritura. La pyeden crear donde quieran. Yo la crearé en C:. También crearé una carpeta en el servidor primario donde la cuenta de SQL Agent tenga permisos de lectura y escritura.

3.- Configuración de la administración remota de SQL Server en la máquina secundaria
En una etapa de la configuración se requiere conectarse a la instancia de la instancia secundaria para poder configurar la base de datos en el destino. Nada más hay que permitir las conexiones por el puerto 1433 TCP en el firewall de la máquina secundaria.

4.- Configuración de log shipping en la base de datos primaria
Se escoge la base de datos y en el menú se escoge: “Ship Transaction Logs”

Ship Transaction Logs

Ship Transaction Logs

Se abrirá una ventana y se debe seleccionar el primer checkbox que aparece. Ese que dice: “Enable this as a primary in a log shipping configuration” y se hace click en el botón Backup Settings.

Configuracion de LogShipping

Configuracion de LogShipping

En Backup settings se configuran las rutas donde irán a parar los log de transacciones en la instancia primaria. Se debe configurar la ruta del recurso compartido y de la carpeta local. Además, se puede configurar la frecuencia de los respaldos, pero para efectos de este artículo no nos meteremos ahí.

BackUp Settings

BackUp Settings

Al momento de hacer click en Ok la ventana se cierra y vuelve a la ventana inicial. Aquí se configura los secundarios.
En la ventana, hacer click en Addy se abrirá otra ventana.

Configuracion Secundario

Configuracion Secundario

Se tienen varias opciones: Respaldar la base de datos automáticamente, copiarla a la otra instancia y restaurarla, restaurar un respaldo ya creado en la segunda instancia, o bien, dejar que todo está OK, siempre y cuando nosotros antes hayamos restaurado la base de datos desde un respaldo.
Para efectos de este artículo, dejaremos que el asistente realice toda la tarea.

Configuracion de Copia de Archvos

Configuracion de Copia de Archvos

Se configura el directorio donde se copiarán los respaldos desde el primario hacia el secundario. Yo configuré la ruta del directorio compartido del servidor secundario.
Una vez que está todo listo, le damos OK a la ventana actual y a la principal.
Aquí comenzará a configurar el servidor primario y el secundario. Una vez que esté listo, mostrará algo así:

Progreso de la configuracion

Progreso de la configuracion

En el servidor secundario ya podemos ver una base de datos que está en constante proceso de restauración.

5.- Prueba
Para ver que todo funcione, bajamos los servicios de SQL Server de la instancia primaria y en el servidor secundario ejecutamos la consulta:
RESTORE MiDB WITH RECOVERY
Y podemos hacer una consulta a los datos que tenemos.

Interesantes puntos

  • El failover no es automático
  • Los Jobs que se encargan de respaldar y restaurar tardan, por defecto, 15 minutos

Nos vemos en la próxima entrega

Agregar un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *