El espejo de bases de datos o Database Mirroring es una solución de alta disponibilidad presente en SQL Server desde la versión 2008. Igual que la solución Always On, funciona a nivel de base de datos pero, en este caso, debe configurarse individualmente en cada base de datos. Una de las instancias actuará como primaria (principal) y otra como secundaria (espejo). Como siempre hacemos, vamos a ver sus características y cómo funciona, sin embargo no vamos a comentar cómo implementarlo. Esta es una solución discontinuada por parte de Microsoft que desaparecerá en futuras versiones de SQL en favor de Always On.
Opciones de implementación de Database Mirroring
Database Mirroring funciona sincronizando la base de datos del servidor principal con la base de datos del servidor espejo. No admite más réplicas. Sin embargo, es posible configurar una tercera instancia como testigo (witness) que se encargará del balanceo automático en caso de fallo en el servidor primario.
La opción más común de implementación de Database Mirroring es con dos servidores SQL cada uno con una instancia replicando una base de datos del principal al espejo. Sin embargo, es posible encontrar Database Mirroring configurados entre instancias de la misma máquina. También es común encontrar una pareja de servidores que son principales para unas bases de datos y espejo para otras. Os dejo esquemas de estas implementaciones sacados de la documentación oficial:
Modos operativos de Database Mirroring
Podemos configurar nuestros Database Mirroring de tres maneras diferentes y, en función de como lo configuremos cambiarán su comportamiento. Como DBAs deberemos decidir cuál se adapta mejor a nuestro escenario.
Modo alto rendimiento
El modo alto rendimiento solo está disponible en versiones Enterprise de SQL Server. Si optamos por este modo no tendremos opción de usar un servidor como testigo. Los datos se enviarán del servidor principal al espejo de manera asíncrona. Al no admitir un servidor testigo, no es posible configurar un balanceo automático en caso de fallo del servidor principal. Cuando esto pasa, podemos esperar a que vuelva a estar operativo el principal (con la base de datos no disponible), forzar un balanceo manual (con posible pérdida de datos) o actualizar manualmente la base de datos espejo con la última copia de log del servidor principal.
Modo alta seguridad
Disponible en todas las versiones de SQL Server el modo alta seguridad envía los datos de manera síncrona, la transacción se confirmará tras el commit en ambos servidores. Puede ser un problema si la latencia de red es elevada. En caso de fallo del servidor principal, los datos en el servidor espejo estarán actualizados y no tendremos perdida de datos. Podremos elegir si queremos esperar con la base de datos no disponible o forzar un balanceo manual sin pérdida de datos.
Modo alta seguridad con balanceo automático
Los datos se escriben de manera síncrona en el servidor principal y el espejo pero necesitaremos de un tercer servidor que haga de testigo. En caso de fallo del servidor principal, el servidor testigo será capaz de detectarlo y automáticamente balanceará el rol, convirtiéndose en principal la base de datos del servidor espejo.
Pros y contras de Database Mirroring
La principal ventaja de esta solución es su facilidad de configuración, no requiere de WSFC y es compatible con todas las ediciones y versiones de SQL Server desde 2008. Todo esto permitiéndonos configurar un balanceo automático. Además, se puede combinar con otras opciones como las FCI, el log shipping o la replicación.
Como hemos empezado comentando, es una solución que será eliminada de futuras versiones de SQL Server en favor de Always On. Siendo soluciones de alta disponibilidad a nivel base de datos, Database Mirroring se debe configurar individualmente por base de datos, no tiene opción de configurar un listener como punto de escucha común para los dos servidores y solo admite una réplica.
Conclusión
Hemos podido conocer los aspectos básicos de Database Mirroring, una solución de alta disponibilidad de SQL Server discontinuada y que se eliminará en un futuro. Como DBAs evitaremos configurar esta solución por los motivos ya mencionados aunque, como todos sabemos, el mundo real es muy diferente a la teoría y por eso debemos conocerlo y tener claro cómo funciona.
[…] Database Mirroring (HA Parte 4) […]
[…] último, igual que vimos en Database Mirroring, podremos configurar una instancia SQL Server de supervisión. En este caso no será encargada del […]