PDF de programación - SQL Server Database Mirroring

SQL SERVER DATABASE MIRRORING

Database Mirroring es una solución alternativa de Alta Diponibilidad, nueva


apartir SQL Server 2005, que puede verse como la evolución natural de Log
Shipping (tecnología disponible en ediciones anteriores de SQL Server, basada
en la entrega de Logs de Transacciones sobre una copia de la base de datos en un
servidor secundario en espera, es decir, hacer RESTORE LOG WITH
NORECOVERY). Así, existen varias diferencias entre Database Mirroring y Log
Shipping, por ejemplo, Log Shipping permite funcionar en Modo de Recuperación
de Registro Masivo (Bulk-Logged) y en el Modo de Recuperación Completo,
mientras que Database Mirroring sólo puede funcionar en Modo de Recuperación
Completo.

A diferencia de Log Shipping, Database Mirroring ofrece recuperación
automática ante fallos (automatic failover) sin necesidad de disponer de
ninguna solución hardware especial ni propietaria, con lo cual, se muestra como
una alternativa de bajo coste a las soluciones basadas en Microsoft Cluster (o
Server Clustering).



 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.