Lunes, 02 Abril 2012 19:51

Log Shipping hacia dos servidores en sql 2005 - I parte

Escrito por
Valora este artículo
(0 votos)

Sql 2005 posee distintos métodos que aseguran la alta disponibilidad de bases de datos, el más conocido y económico en todo sentidos es el log shipping. El problema es que en la versión 2005 es posible replicar solo hacia un servidor secundario. La solución que se presenta permite replicar hacia más de un servidor secundario.


El método del log shipping es un sistema seguro y relativamente fácil de configurar para replicar bases de datos en modo asincrónico, y es el método más usado para mantener sistemas en alta disponibilidad; ya que es un sistema económico, fácilmente configurable, que no requiere elevado esfuerzo de administración.

Cuando dos servidores están en log shipping, en uno de ellos (denominado "primario") es posible trabajar normalmente, mientras que el segundo (denominado "secundario") mantiene una copia eventualmente de solo lectura sincronizadas casi en tiempo real. En caso que el servidor primario no funcione, es posible destruir el log shipping y usar el secundario. Este proceso, que es manual, puede automatizarse mediante la configuración de otro servidor (llamado "testigo") mediante el cual se monitorea automáticamente que el log shipping esté funcionando y que el primario esté respondiendo y -caso contrario- elevar el secundario a primario destruyendo el log shipping.

Para comprender como implementar esta solución, es necesario recordar que todo este método se basa básicamente en una serie de jobs que realizan en forma periódica un backup del log sobre el servidor primario, transfieren estos archivos al servidor secundario y realizan allí la restauración de estos archivos. Para simplicidad además, se considerará una replicación hacia dos servidores secundarios sin servidor testigo, pero el procedimiento de fondo no cambia si agregamos más secundarios y un testigo.

La implementación del log shipping consiste básicamente en tres pasos:

  1. Crear el backup de la base de datos original (el servidor primario)
  2. ejecutar el restore de esta base de datos con la opción "with no recovery" en el servidor secundarion (y eventualmente con la opción "with standby")
  3. realizar el backup del transaction log en el servidor primario periódicamente
  4. mover el archivo de backup creado en el punto anterior, y
  5. realizar el restore de este backup sobre la base de datos del servidor secundario (siempre con la opción "with no recovery" y eventualmente con la opción "with standby")

Hasta la versión de sql server 7, estos pasos se hacían manualmente, a partir de sql server 2000 se ejecutan en modo manual mediante tres jobs:

  • un job que se ejecuta en el primario para realizar el backup del transaction log (paso 3 de la explicación anterior)
  • un job que se ejecuta en el secundario para copiar el archivo de backup a otra carpeta (paso 4 de la explicación anterior)
  • un segundo job que se ejecuta en el secundario para realizar el restore del backup copiado en el punto anterior (paso 5)

Obviamente esto presupone que los pasos 1 y 2 ya fueron realizados por el dba (aunque es posible delegar esta operación al wizard de sql management studio).

El problema con sql 2005 es que no es posible realizar el log shipping hacia más de un servidor secundario (fue agregado a partir de sql 2008). En la segunda y última parte veremos como "engañar" al sistema para que esto sea posible con poco esfuerzo.

Leer 5788 veces Modificado por última vez en Miércoles, 30 Mayo 2012 17:07
Volver arriba