Continuamos con la serie de artículos sobre alta disponibilidad, hoy hablaremos de Log Shipping. Log shipping es una técnica de alta disponibilidad que permite replicar los datos de una base de datos de SQL Server en una o varias bases de datos secundarias. De esta forma, podremos tener una copia actualizada (o casi) de los datos en caso de que la base de datos principal falle o se pierda. También nos va a permitir crear copias de sólo lectura de nuestra base de datos en otra ubicación.
¿Cómo funciona Log Shipping?
Log Shipping funciona mediante la creación y el envío periódico de copias de seguridad del log de transacciones de la base de datos principal a las bases de datos secundarias. Estas copias de seguridad se restauran en las bases de datos secundarias, aplicando así los cambios que se han producido en la base de datos principal.
Cuando configuremos Log Shipping se crearán una serie de jobs en las instancias SQL Server principal y secundarias para hacer las copias de seguridad, moverlas y restaurarlas. Podremos cambiar manualmente las programaciones de estos jobs en función de la periodicidad que deseemos en las instancias secundarias. Esto marcará en gran medida nuestro RPO, por defecto será una copia de seguridad cada 15 minutos pero podemos reducirlo si lo necesitamos.
Pros y contras de Log Shipping
Ventajas
Log shipping es una solución sencilla y económica que no requiere de licencias Enterprise ni clústers complejos para funcionar. Nos va a permitir tener varias bases de datos secundarias, lo que puede mejorar el rendimiento de las consultas de solo lectura y la distribución geográfica de los datos. Además, podremos tener un control total sobre el proceso, ya que se puede configurar la frecuencia, el horario y el modo de envío y restauración de las copias de seguridad. Por último, nos va a ayudar a mantener un RTO relativamente bajo, ya que se puede usar la base de datos secundaria como principal en caso de emergencia.
Inconvenientes
Sin embargo, Log Shipping también tiene algunas limitaciones. No garantiza una sincronización en tiempo real, siempre habrá un retraso entre la base de datos principal y las secundarias dependiendo del intervalo de copia de seguridad y restauración. Esto implica que los objetivos RPO y RTO pueden no ser tan bajos como con otras soluciones. Con Log Shipping, el RPO y el RTO dependen del intervalo configurado para las copias del log.
A nivel operativa diaria, no permite realizar cambios en la estructura o el esquema de la base de datos principal, ya que estos cambios no se replican a través de copias de log de transacciones. Tampoco nos va a permitir en ningún momento tener bases de datos secundarias en modo lectura/escritura. No es compatible con algunas características de SQL Server, como la compresión de datos, el cifrado transparente de datos o las instantáneas de base de datos. Ni con otras soluciones de alta disponibilidad como los Always On (aunque se puede llegar a hacer funcionar no es una solución aprobada por Microsoft.)
Además, no nos va a facilitar ninguna opción de balanceo automático. En caso de error, tendremos que activar manualmente la base de datos secundaria y redirigir a ella todas las conexiones.
Opciones de implementación de Log Shipping
Hemos dicho antes que en Log Shipping podemos tener las copias secundarias accesibles en modo lectura. Esto lo tendremos que configurar cuando configuremos la restauración en el servidor secundario. Tendremos la opción de restaurar las copias de seguridad en modo NORECOVERY o STANDBY. El modo STANDBY nos permitirá mantener nuestras bases de datos secundarias accesibles para lectura. Sin embargo, solo podremos hacerlo si el servidor principal y el secundario tienen la misma versión de SQL Server. Tendremos que usar el modo NORECOVERY si nuestra base de datos secundaria es de una versión superior a la principal.
Tendremos también la posibilidad de modificar el comportamiento de nuestro Log Shipping modificando los jobs que genera. En el servidor principal tendremos dos jobs, uno encargado de hacer las copias de seguridad de log de transacciones y otro que comprobará si se hacen las copias y enviará alertas en caso contrario. Es importante que no tengamos ninguna otra copia de seguridad de log fuera de este job o Log Shipping dejará de funcionar.
En el servidor secundario nos encontraremos tres jobs, el de copia de los archivos de copia de seguridad del servidor principal al secundario, el de restauración y otro de monitorización.
Por último, igual que vimos en Database Mirroring, podremos configurar una instancia SQL Server de supervisión. En este caso no será encargada del balanceo pues no tenemos opción de automatizarlo, pero sí que recibirá y almacenará el estado actual y el historial de nuestro Log Shipping.
Conclusión
Aunque siempre se habla de Log Shipping como una solución de alta disponibilidad y hasta yo lo he tratado como tal hasta este punto, realmente no lo es. Como hemos podido ver, debido a sus limitaciones de RPO y RTO la alta disponibilidad real queda muy lejos de esta solución. Sin embargo, me parece una técnica muy útil para mantener una copia actualizada y disponible de los datos en SQL Server. Esto lo convierte en una solución ideal para un DRP o para tener copias de sólo lectura de nuestro servidor de producción, por ejemplo en servidores de análisis o DWH.
Espero que este artículo te haya ayudado a entender mejor qué es Log Shipping y cómo implementarlo en SQL Server. Si tienes alguna duda o comentario, no dudes en dejarlo abajo, en Twitter o por mail. Estaré encantado de ayudarte. ¡Hasta la próxima!
[…] Log Shipping (HA Parte 5) […]