Alta disponibilidad con Log Shipping en SQL Server

30/05/2012

Una de las formas más comunes de tener alta disponibilidad en SQL Server es con Log Shipping. Con este modo, lo que hacemos es tener una o más instancias de sql server en modo de sólo lectura en las que restauramos el log de cambios  de la base de datos cada cierto tiempo.  El log shipping es un método barato, sencillo y alternativo a otros métodos de alta disponibilidad tal como por ejemplo el cluster o el mirror.

La principal diferencia con el mirror, es que el log shipping permite tener la segunda instancia en modo Standby, lo que permite acceder a esta instancia en modo sólo lectura (read-only). Hay muchas empresas que por ejemplo tienen la base de datos online (instancia primaria) con todo el negocio y luego tienen las instancias secundarias en modo sólo lectura, por ejemplo con los reportes de SQL Server para no cargar a la primaria. Otra diferencia es que pueden tenerse más de una instancia secundaria, cosa que en el mirror, sólo puedo tener una secundaria. La principal desventaja con el mirror se refiere al failover automático que no tenemos en Log Shipping, sino que lo tenemos que hacer manual.

Para hacer el Log Shipping se necesita tener al menos 2 instancias, una de ellas llamada primaria y otra secundaria. Para que el log pueda compartirse, se necesita una carpeta compartida que puedan ver las dos instancias y una carpeta local en cada instancia donde se pueda “copiar/restaurar” desde/hacia la base de datos a la carpeta compartida. Los pasos serían así:

1. La instancia primaria hace una copia de seguridad de log y la deja en una carpeta local y la copia en una carpeta compartida (normalmente la carpeta local y la compartida suelen coincidir).

2. Se copia el fichero de log de la carpeta compartida del servidor primario a la carpeta local del secundario

3. Se restaura el fichero de log de la carpeta local del secundario

Arquitectura de Jobs en Log Shipping

Arquitectura de Jobs en Log Shipping

Para cada uno de estos pasos, SQL Server genera un job propio que podemos programar para que se ejecuten a una hora y día determinado. Por defecto, está configurado cada 15 minutos, aunque en este ejemplo que estoy haciendo lo he programado todo para que se haga cada 1 minuto.

Por tanto, el primer paso para crear el log shipping es tener una carpeta compartida y carpetas locales en dos instancias. A nivel de permisos, tenemos que tener en cuenta que el SQL Server Agent es el que tiene que hacer la backup/restore y copy en las carpetas, osea tenemos que dar permisos en dichas carpetas al agente.

El segundo paso es activar el log Shipping. Para eso, seleccionamos la base de datos (fijémonos que es a nivel de base de datos y no de instancia) en la queremos activar, botón derecho del ratón y seleccionamos Propiedades. En las propiedades, seleccionamos Log Shipping. Veremos que tenemos opciones para configurar el servidor primario y el secundario.

En el servidor primario, debemos indicar dónde la carpeta local y la carpeta compartida que utilizarán las dos instancias. También podemos indicar si queremos que se haga la copia de seguridad inicial de la base de datos y posteriormente se active la copia de los logs. Antes de que se puedan restaurar los logs, tiene que haberse restaurado una vez la base de datos entera.

Configuración del Servidor Primario en Log Shipping

Configuración del Servidor Primario en Log Shipping

El siguiente paso es configurar el servidor secundario. En él indicamos la carpeta local donde queremos que se copie el log (pestaña de Copy files) y también podemos indicar cómo queremos que se restaure dicho log (pestaña Restore Transaction Log): en modo NO RECOVERY o en modo STANDBY. El modo STANDBY permite que podamos aplicar logs y que podamos consultarlo y que por si algún motivo no es el log que necesitamos, poder restaurar otro log posterior. Gracias a ello, podremos tener la base de datos secundaria en modo sólo lectura.

Configuración del servidor secundario en Log Shipping

Configuración del servidor secundario en Log Shipping

Una vez tengamos los dos servidores configurados, ya sólo queda activar el Log Shipping con la opción “Enable this as a primary database in a log shipping configuration” y listo.

Propiedades de configuración del Log Shipping

Propiedades de configuración del Log Shipping

A partir de este momento, empezaremos a ver que en la carpeta local y compartida aparecen las copias de la base datos inicial y las subsiguientes del log.

Ficheros del log que se generan una vez activado el Log Shipping

Ficheros del log que se generan una vez activado el Log Shipping

Puede que cuando iniciemos el log shipping no funcione. Si hemos utilizado el asistente tal y como hemos explicado aquí, veremos que aparece este error:  Could not retrieve copy settings for secondary ID ‘[removed]’.(Microsoft.SqlServer.Management.LogShipping). Si buscamos en internet, vemos que el asistente del log shipping tiene un bug. En esta página web está muy bien explicado:

http://ms-dba.blogspot.com.es/2010/06/copy-and-restore-job-errors-with-log.html

En concreto los dos jobs que genera en el servidor secundario, la instancia que se indica para hacer la copia y restauración, es la primaria en vez de la secundaria. En el parámetro -server, hay que indicar el nombre de la instancia secundaria.

“C:\Program Files\Microsoft SQL Server\100\Tools\Binn\sqllogship.exe” -Copy {ID} -server SQLInstanceMirror

“C:\Program Files\Microsoft SQL Server\100\Tools\Binn\sqllogship.exe” -Restore {ID} -server SQLInstanceMirror

Una vez actualizados los dos jobs, podemos ejecutarlos y veremos que el log shipping empieza a funcionar.

¿Cómo comprobamos que funciona?

1. Comprobando que en las carpetas locales y compartidas aparecen las copias de los logs

Ficheros del log que se generan una vez activado el Log Shipping

Ficheros del log que se generan una vez activado el Log Shipping

2. Que están definidos los jobs en los SQL Server Agent de los servidores y que se están ejecutando

Jobs generados en la base de datos secundaria en Log Shipping

Jobs generados en la base de datos secundaria en Log Shipping

3. Accediendo en modo sólo lectura a la base de datos secundaria y comprobando que se restaura cualquier cambio

Base de datos secundaria en modo Standby (sólo lectura)

Base de datos secundaria en modo Standby (sólo lectura)

14 comentarios to “Alta disponibilidad con Log Shipping en SQL Server”


  1. Excelente, ya lo tengo funcionando … me preguntaba si podrías hacer un manual parecido pero ocupando mirror.

  2. jftamames Says:

    Reblogged this on Tendencias jftamames and commented:
    En algunos clientes el uso de esta tecnología les está sirviendo como para asegurarse restauraciones dentro de la ventana que le exige el negocio.

  3. javet Says:

    hola hice lo ue describes en tu blog pero no active el servirdor secundario, solo quiero que se creen los logs y se guarden en una ruta especificada pero no me funciono, podrias ayudarme?


    • Hola,

      La primera ver debes copiarlos tú a mano. Luego se crear unos jobs que se encargan de replicar el log. Revisa en el agente del SQL Server dichos jobs y si hay algún problema con ellos

  4. Wally Says:

    Reblogueó esto en wallydicey comentado:
    Interesante…

  5. Luis Says:

    que pasa si tenemos plan de backups (full y log) en la base principal? se tienen que desactivar el plan de los logs? no tendra problema en restaurar el log en la secundaria despues de hacer el backup full en la principal?

  6. rjzue Says:

    Oye pero y que opciones verias tu para las versiones express de sql server???


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: