Database Mirroring es una solución de Alta Disponibilidad en SQL Server, disponible desde SQL Server 2005 y sensiblemente mejorada en SQL Server 2008, mostrándose como una alternativa a los sistemas de Alta Disponibilidad basados en Microsoft Cluster y/o Replicación de Almacenamiento Datos, siendo también una alternativa interesante a otras tecnologías como Log Shipping o a la Replicación de SQL Server.
Database Mirroring, al igual que Log Shipping, sólo protege a nivel de base de datos (es decir, sólo las bases de datos de usuario) y no a nivel de Instancia, para lo cual sería necesario implementar Server Clustering (y así proteger también las bases de datos del sistema y demás elementos que forman una instancia de SQL Server).
Database Mirroring es una tecnología de Alta Disponibilidad basada en un modo de funcionamiento Activo / Pasivo. Es decir, mientras una Instancia realiza un papel de Servidor Principal (Activo) para una base de datos en particular, la otra instancia realiza el papel de Servidor Espejo o Secundario (Pasivo) para dicha base de datos. En consecuencia, no será posible el acceso a la copia de la base de datos del Servidor Espejo.
Database Mirroring requiere que la base de datos que se desee proteger, esté configurada con el Modo de Recuperación Completo (Full Recover Model), algo bastante evidente, al tratarse de una tecnología que basa su funcionamiento en el envío de transacciones de una base de datos principal a una base de datos espejo o secundaria.
Es posible montar Database Mirroring sobre SQL Server 2005 y SQL Server 2008. El hecho de poder montar el Servidor Principal sobre SQL Server 2005 y el Servidor Espejo sobre SQL Server 2008, permite plantearse soluciones de Database Mirroring interesantes para Migraciones de SQL Server 2005 a SQL Server 2008 con a penas corte de servicio y luego romper el Database Mirroring, si no lo queremos mantener.
Es importante tener en cuenta que NO es posible hacer funcionar Database Mirroring con el Servidor Principal en SQL Server 2008 y el Servidor Espejo en SQL Server 2005
Los posibles papeles o roles que puede desempeñar una instancia de SQL Server en una solución de Database Mirroring son:
• Servidor Principal. Mantiene la copia activa de la base de datos (base de datos principal), a través de la cual, se ofrece el servicio a los usuarios. Todas las transacciones son enviadas al Servidor Espejo antes de aplicarlas en la base de datos principal.
• Servidor Espejo (Mirror). Mantiene una copia de la base de datos principal (base de datos espejo o mirror database), y aplica todas las transacciones enviadas por el Servidor Principal, manteniendo sincronizada la base de datos espejo.
• Servidor Testigo (Witness). Se trata de un elemento opcional. No es obligatorio o necesario implementar un Servidor Testigo (Witness) en una solución de Database Mirroring. Sin embargo, si deseamos que nuestra solución de Database Mirroring ofrezca recuperación automática ante fallos (automatic failover), entonces sí será necesario implementar un Servidor Testigo (Witness Server), pues éste es quién monitorizará los Servidores Principal y Espejo partícipes de una Sesión de Espejo (Mirror Session) con el objetivo de asignar el papel de Principal al servidor Espejo en caso de una caída de servicio o pérdida del primero (es decir, en caso de caída del Servidor Principal, se asignará el papel de Principal al Servidor Espejo, manteniéndose así el servicio). El trabajo realizado por el Servidor Testigo (Witness) no es muy intenso, por lo cual, no requiere de grandes recursos, y además, un mismo servidor puede actuar como Servidor Testigo (Witness) para múltiples sesiones de espejo, sin pérdida de rendimiento.
Database Mirroring ofrece tres modos de funcionamiento, como antes adelantamos:
• Modo de Alta Disponibilidad (síncrono y con testigo). Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Requiere de un Servidor Testigo (Witness) ubicado sobre una tercera máquina (que no sea ni el Servidor Principal ni el Servidor Espejo), gracias al cual es posible la recuperación automática ante fallos (automatic failover) o conmutación automática de roles. En caso de fallo del Servidor Principal durante el envío de transacciones, el Servidor Espejo tiene que terminar las transacciones encoladas antes de poder levantarse como Servidor Principal. Por supuesto también es posible la recuperación manual ante fallos (manual failover) o conmutación manual de roles. En caso de una caída o pérdida del Servidor Espejo, la base de datos principal se mantendrá activa.
• Modo de Alta Protección (síncrono y sin testigo). Las transacciones son aplicadas de forma síncrona a las base de datos principal y espejo. Sin embargo, no utiliza un Servidor Testigo (Witness). En este modo de funcionamiento, no es posible la existencia de pérdida de datos, pero la recuperación ante fallos se realiza de forma manual (manual failover). En caso de una caída o pérdida del Servidor Espejo, la base de datos principal dejará de estar activa, al haber perdido el Quorum.
• Modo de Alto Rendimiento (asíncrono y sin testigo). Las transacciones son aplicadas de forma asíncrona a la base de datos espejo, ofreciendo mejor rendimiento que los anteriores modos de funcionamiento, pero pagando como precio la existencia de posibles pérdidas de transacciones (y en consecuencia, potenciales pérdidas de datos). Evidentemente, la recuperación ante fallos se realiza de forma manual (manual failover), hablando de conmutación forzada (es decir, cambio de roles sin comprobación de datos escritos en el servidor espejo). En caso de una caída o pérdida del Servidor Espejo, el Servidor Principal no se verá afectado.
1. Primeramente preparamos nuestra base de datos espejo en nuestro server o instancia que fungirá como tal, aquí dos puntos importantes: Que la base datos que restauremos sea el ultimo backup realizado desde la principal. A la hora de restaurarla tenemos que marcar la opción de NON RECOVERY.
2. En el Management Studio, Explorador de Objetos, Seleccionamos una base de datos, hacemos click derecho sobre ella en la opción, Task, Mirror.
3. El primer paso sería configurar la seguridad, para lo cual vamos a seguir un asistente.
En el primer paso del asistente nos preguntara si queremos tener una instancia de testigo, para este primer ejempo le diremos que No.
4. Luego definiremos el servidor principal
5. Ahora definiremos nuestra instancia o servidor espejo
6. En este paso se definen las cuentas de usuario que utilizaran tanto el servidor principal como el espejo que estén en un dominio. Para nuestro ejemplo dejaremos en blanco esta opción.
7. Finalmente terminanos de configurar el asistente de seguridad.
8. Una vez finalizado nos pedirá si deseamos iniciar el mirroring, le diremos iniciar.
9. Ya tendremos configurado nuestro mirroring como se muestra en la pantalla siguiente, desde aquí podemos iniciar el mirroring, y podemos configurar el tipo de operación que deseamos, tal y cual se planteo al inicio del articulo. Hacemos click en OK.
La Redirección Automática del cliente en una infraestructura de Database Mirroring, es una funcionalidad muy apreciada, y en este caso, es tan fácil como utilizar una sintaxis determinada en la cadena de conexión a SQL Server, como se muestra en el siguiente:
"Data Source=PORTATIL;Failover Partner=PORTATIL\MIRROR;Initial Catalog=Demo;Integrated Security=True;"
