Introducción a Database Mirroring en SQL Server

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). Además, para casos de balanceo (failover), es posible desarrollar las aplicaciones cliente para que se re-conecten automáticamente a la base de datos activa (es decir, a la que actúe como base de datos principal), como se indica más adelante en el capítulo de Administración y Mantenimiento de Database Mirroring (ver la sección Redirección de Cliente: ADO.NET / SQL Native Client automatic redirection).

Es importante tener en cuenta, que a día de hoy, en cualquier mediana o gran empresa abundan las soluciones SAN (ej: almacenamiento HP EVA, redes y switches de fibra, etc.) y los servidores Wintel con interfaces HBA (ej: servidores HP Blade, HP SuperDome, etc), infraestructuras sobre las cuales es posible construir soluciones Microsoft Cluster de forma sencilla y económica (es decir, tomando como premisa la existencia de dicha infraestructura, no es necesario ningún elemento adicional para montar un Microsoft Cluster, por lo tanto, nos da igual montar SQL Server sobre Microsoft Cluster o un Database Mirroring, desde el punto de vista de costes adicionales, al menos en principio).

Una ventaja de montar Database Mirroring en vez de Microsoft Cluster (o Server Clustering), la podríamos encontrar si tuviéramos que ofrecer Alta Disponibilidad de base de datos para un producto que no esté soportado su funcionamiento con bases de datos en Cluster. Por poner un ejemplo real, en una instalación MOSS 2007 (Microsoft Office SharePoint Server 2007) o Microsoft Office Sharepoint Portal Server 2003 no están soportados para ejecutarse sobre bases de datos SQL Server 2005 en Cluster Geográficos, conforme muestra el artículo de soporte KB946791, aunque sí se tratan de aplicaciones Cluster-Aware (es decir, sí pueden montarse sobre Microsoft Cluster, siempre y cuando, no exista replicación del almacenamiento entre ubicaciones físicamente separadas). En este caso, la forma de ofrecer un entorno de Alta Disponibilidad de base de datos geográficamente disperso, pasa por utilizar Database Mirroring (pudiendo ubicar los servidores miembros de la correspondiente sesión de Mirroring, en ubicaciones físicamente distantes).

La comunicación entre los diferentes servidores SQL Server de una topología Database Mirroring, se realiza a través de Extremos o Endpoints de SQL Server específicos para Database Mirroring, un tipo de objeto de servidor nuevo en SQL Server 2005, que permiten la creación de caminos de comunicación con Instancias de SQL Server. La ventaja de la utilización de Extremos o Endpoints, es que permiten configurar sus requisitos de Autenticación y Cifrado, ofreciendo así un camino de comunicación más o menos seguro (en función de las necesidades de cada caso). Por defecto, la creación de Extremos o Endpoints (CREATE ENDPOINT) para Database Mirroring a través del Asistente incluido en SQL Server 2005, implicará la creación de Extremos o Endpoints con Autenticación y Cifrado.

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, pues en dicho caso, se producirá un error como el siguiente:

Msg 954, Level 14, State 1, Line 1
The database "GuilleSQL" cannot be opened. It is acting as a mirror database.

Sin embargo, aunque el funcionamiento de Database Mirroring es Activo/Pasivo, tanto el servidor Principal como el servidor Espejo hospedan ambos una copia de la base de datos, con la peculiaridad de que la base de datos del servidor que actúa como Espejo no podrá ser accedida (sólo estará accesible la base de datos Principal), pues estará en modo Mirror / Restoring. Claro está que podemos encontrar un pequeño truco si deseamos acceder a la base de datos Espejo (Mirror), pues es posible crear un Database Snapshot sobre la base de datos en Mirror, y seguidamente consultar dicho Database Snapshot (evidentemente, sólo podremos consultar los datos conforme estaban en un punto en el tiempo, no siendo posible modificar datos). Algo sorprendente (al menos, a mi me lo pareció cuando lo descubrí), pues de hecho, sobre una base de datos en modo Restoring no es posible crear un Database Snapshot, pero sin embargo, sobre una base de datos en Mirror sí es posible (que al fin y al cabo, se está comportando de un modo muy parecido al de Restoring, aplicando las transacciones del principal continuamente). Más adelante en este artículo, se incluye algún ejemplo de Database Snapshot sobre Database Mirroring.

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.

Database Mirroring sólo está disponible en las ediciones SQL Server 2005 Enterprise y Developer (actualizado 24/07/2009: en la Standard también), por lo tanto, no podremos utilizar Database Mirroring en SQL Server 2005 Workgroup, ni Express. Sin embargo, la Instancia que realice el papel de Servidor Testigo (Witness), puede ser de cualquier edición de SQL Server 2005, de tal modo, que sería posible ejecutar el Servidor Testigo sobre un servidor SQL Server 2005 Express en una máquina separada de los Servidores Principal y Espejo (más adelante se detallan los distintos roles de una topología de Database Mirroring). Más información:

• Comparación Características SQL Server 2005
• Comparación Características SQL Server 2008

Una instalación basada en Database Mirroring requiere un mínimo de dos Instancias de SQL Server 2005: una de las Instancias realizará el papel de Principal, mientras que la otra Instancia realizará el papel de Secundaria o Espejo, manteniéndose en espera (ojo, que es concepto de Principal y Espejo es a nivel de base de datos y no de instancia, es decir, en una instancia puede haber varias bases de datos en Principal, otras en Espejo, y otras sin Mirroring). En consecuencia, la base de datos que se desea proteger deberá ser copiada desde el servidor Principal al servidor Espejo (con Backup y Restore, como se describe más adelante), teniendo en cuenta que la base de datos principal y espejo deben mantener el mismo nombre. Como comentamos antes, es posible incorporar una tercera instancia a una solución de Database Mirroring, la cual realizará un papel de árbitro o testigo.

Resumiendo, 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.

Vuelvo a insistir en que dichos Roles son a nivel de Base de Datos. Es decir, un servidor SRV_A puede actuar como principal para una base de datos BD_A, siendo un servidor SRV_B quien actúa como espejo (mirror) para dicha base de datos. Sin embargo, nada impediría, que para una base de datos BD_B, sea SRV_B el principal y SRV_A el espejo (mirror). Del mismo modo, para la BD_A se podría utilizar un servidor SRV_C como Testigo (Witness), y para la BD_B se podría utilizar otro servidor SRV_D como Witness. Claro, que todo esto tiene sentido desde un punto de vista didáctico. En un entorno empresarial, es muy probable que se disponga de un CPD principal y un CDP de reserva (BDC), de tal modo que en el CPD principal se sitúe un Servidor que actúe como principal para todas las bases de datos, mientras que en el CPD secundario se sitúe un servidor que actúe como espejo (mirror) para todas las bases de datos, utilizando un único servidor adicional (en caso de que se desee Automatic Failover) para actuar como servidor Testigo (Witness) para todas las bases de datos.

Database Mirroring no estaba disponible por defecto en la primera versión de SQL Server 2005, de tal modo, que sólo era posible habilitar Database Mirroring activando el Trace Flag 1400 como parámetro de inicio de la correspondiente Instancia de SQL Server 2005, (no es suficiente con DBCC TRACEON, debe establecerse el parámetro de inicio -t1400). De hecho, en la primera versión de SQL Server 2005, Database Mirroring no estaba soportado para entornos de Producción. La disponibilidad de Database Mirroring para entornos de Producción fue a partir de SQL Server 2005 SP1, versión a partir de la cual, ya no era necesario activar el Trace Flag 1400.

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.

Por poner un ejemplo, en el caso de MOSS 2007 (también con SharePoint Portal Server 2003), para ofrecer un sistema de Alta Disponibilidad basado en servidores SQL Server geográficamente dispersos, el modo de funcionamiento recomendado será el Modo de Alta Disponibilidad, debido a que MOSS 2007 (o SharePoint 2003) contiene múltiples bases de datos, siendo necesario mantener la consistencia e integridad sobre todas las bases de datos SQL Server utilizadas por MOSS 2007 (o SharePoint 2003). En consecuencia, también sería posible utilizar el modo de funcionamiento de Alta Protección, en cuyo caso se perdería la funcionalidad de recuperación automática ante fallos (Automatic Failover), pero sin riesgo de pérdida de datos. Un aspecto a tener en cuenta en caso de montar Database Mirroring para MOSS 2007 o SharePoint 2003, es el tema de la configuración de Alias SQL, como se comentó en un artículo anterior de Instalación y Configuración MOSS 2007.

A continuación se incluye una tabla resumen de los modos de funcionamiento de Database Mirroring en SQL Server 2005: