Implementando database mirroring con SQL Server 2005

Hace poco una empresa que tiene una aplicación Web, me pidió apoyo para mudar los servidores que alojan esta aplicación, de un hosting a un modelo de collocation en un Internet Data Center (IDC). Esta aplicación fue desarrollada con Visual Basic.NET, y la interfaz de usuario está hecha con páginas ASPX, y el motor de base de datos es SQL Server 2000.

La idea inicial de esta mudanza era la de poder utilizar las bondades y capacidades del IDC, y a la vez ser los dueños de los equipos que alojan la aplicación (en el modelo de hosting, el dueño de los equipos es la empresa que brinda el servicio de hosting). En el modelo anterior de hosting, la base de datos estaba instalada en un SQL Cluster Activo-Pasivo lo que permitía la continuidad del servicio de base de datos en el evento que el servidor principal fallase.
Sin embargo el costo de alquiler de espacio físico en el SAN (Storage Area Network) en el IDC era extremadamente alto, ya que el mínimo que se podía alquilar eran 50GB a US$ 1.500 mensuales.

Se imaginarán que al cabo de un año, ahorrando todo ese dinero, nos podríamos comprar un propio SAN. Adicionalmente el tamaño de la base de datos de la aplicación, no llega a 3GB.
Entonces se nos ocurrió que, si en fechas pasadas habíamos pensado en migrar a SQL Server 2005, podríamos usar la nueva característica de database mirroring y de esa manera ahorrarnos los costos de alquiler de un SAN. Para los que no lo conocen aún, database mirroring es una nueva característica que viene con la versión 2005 de SQL Server de Microsoft. Esta nueva herramienta, permite crear una imagen exacta de una base de datos de un servidor a otro servidor, sin la necesidad de invertir en un modelo de cluster.

La diferencia entre un modelo de cluster y un database mirroring, radica más que cualquier otra cosa en los costos asociados a la implementación de uno u otro modelo. En el caso de un cluster, es indispensable contar con una matriz de discos externa, y como todos sabemos es algo costoso, por otro lado esta la necesidad de mantener ambos nodos de un cluster con especificaciones técnicas muy similares por no decir exactas.

Por oto lado, el modelo database mirroring es menos exigente. En primer lugar no necesitamos una matriz de discos externos, o sea que podemos tener instalada la base de datos en un disco en un servidor y un espejo de la misma base de datos en otro disco de otro servidor, adicionalmente los servidores no necesitan tener las mismas especificaciones técnicas para poder implementar database mirroring.

Para configurar un ambiente de database mirroring, necesitamos tres equipos:
•
Un servidor Principal que es el que aloja la base de datos de producción.
•
Un servidor Espejo (mirror) que es el que tiene la imagen de la base de datos en producción.
•
Un servidor Testigo (Witness) que se encarga de monitorear el estado del servidor Principal y del servidor Espejo. Este último es necesario si deseamos tener un Failover automático.
Para implementar database mirroring necesita hacer dos cosas muy particulares que en su momento puede afectar una implementación si no las consideramos a detalle.

La primera que podemos mencionar es que para poder utilizar database mirroring necesitamos tener la base de datos con el modelo de recuperación Completo (Full Recovery), esto por la necesidad de escribir en el log de transacciones que se llevan a cabo en la base de datos ya que estas mismas transacciones se van a ir escribiendo en el log de la base de datos espejo.

La segunda y muy importante, es que la aplicación debe tener la inteligencia suficiente para poder conectarse al servidor de base de datos espejo en el caso que el principal falle. Esto lo puede hacer colocando en un bloque Try Cash las cadenas de conexión.

Comento de estas dos cosas ya que la primera de ellas me generó un problema enorme. Sucede que en la base de datos existían una cantidad de transacciones que quedaba abiertas lo que al momento de implementar el mirroring, hizo que el log de transacciones creciera a tal punto que ocupara todo el resto de espacio en disco (el log llegó a pesar casi 40 GB).

Este problema lo resolvimos con el apoyo de algunos colegas en los foros de los MVPs, y de PanITPro en Panamá http://www.PanITPro.org y quiero en este artículo dar las gracias a todos, especialmente a mi amigo Miguel Egea de España, quien a pesar de que nos encontramos a gran distancia, saco de su tiempo para ayudarme a encontrar una solución.

Por otro lado cuando ya resolví el problema del log, sucede que al hacer la prueba de Failover, la aplicación no podía encontrar el servidor espejo, ya que en la cadena de conexión, esta aplicación sólo apuntaba a el principal, por lo cual hubo que reescribir esta porción de código.

Lo que a continuación deseo compartir con ustedes son algunas cosas que deben considerar y/o revisar al momento de implementar este modelo de Failover que de hecho al final del camino me esta funcionando con éxito.

1. Utiliza el SQL Server Profiler para realizar trazas de transacciones que pueden quedar abiertas.
2. Utiliza el monitor de database mirroring para revisar el estado de los servidores.
3. Crear jobs (en el principal) que saquen respaldos periódicos del log para poder truncar las transacciones confirmadas (no puede utilizar backup log [base de datos] with truncate_only en el modelo database mirroring)
4. Recuerda shrinkfile, para reducir el log una vez lo ha respaldado.
5. Configura alertas de rendimiento (en el principal) para monitorear el crecimiento del log de transacciones y el estado de los servidores.
6. Realiza pruebas de Failover, baje el servicio de base de datos del servidor principal, confirme que el espejo tomo el rol del principal y que la aplicación sigue activa.
7. Cuando vuelva a levantar el servidor que era principal, este va a quedar siendo servidor espejo, si desea que vuelva a ser servidor principal, sólo debe bajar los servicios del servidor que antes era espejo y ahora es servidor principal (espero no confundirlos pero así es que se debe hacer).
8. No deje de hacer respaldos completos de la base de datos del Principal
9. Utiliza Alias para los nombres de los servidores y poder usar estos en las cadenas de conexiones.
10. Prepare un proyecto de Integration Services que le permita migrar las cuentas de usuarios que tiene en el servidor Principal al Servidor Espejo.

Espero que esto los ayude a implementar una política de database mirroring y que estos comentarios y consejos le sean de utilidad a aquellos que desean implementar este modelo de Failover.

Good Luck

Dino

Fuente:
Javier Vega - Microsoft