Testigo de creación de reflejo de la base de datos

Artículo
09/10/2013

Para admitir la conmutación automática por error, una sesión de creación de reflejo de la base de datos debe configurarse en modo de alta seguridad y tener una tercera instancia de servidor, denominada el testigo. El testigo es una instancia opcional de SQL Server que habilita al servidor reflejado en una sesión en modo de alta seguridad para que reconozca si se debe iniciar una conmutación automática por error. A diferencia de los dos asociados, el testigo no sirve a la base de datos. El único rol del testigo es hacer posible la conmutación automática por error.

[!NOTA]

En el modo de alto rendimiento, el testigo puede afectar negativamente a la disponibilidad. Si se configura un testigo para una sesión de creación de reflejo de la base de datos, el servidor principal debe conectarse al menos a otra de las instancias de servidor, el servidor reflejado o el testigo, o bien a ambos. De lo contrario, la base de datos no estará disponible y no se podrá forzar el servicio (con posible pérdida de datos). Por lo tanto, para el modo de alto rendimiento, se recomienda mantener el testigo establecido siempre en OFF. Para obtener información acerca del impacto del testigo en el modo de alto rendimiento, vea Modos de funcionamiento de la creación de reflejo de la base de datos.

En la siguiente ilustración se muestra una sesión en modo de alta seguridad que incluye un testigo.

Sesión de creación de reflejo con un testigo

En este tema:

Usar un testigo en varias sesiones
Recomendaciones de software y hardware
Rol del testigo en la conmutación automática por error
Para agregar o quitar un testigo

Usar un testigo en varias sesiones

Una instancia de servidor específica puede actuar como testigo en sesiones de creación de reflejo de la base de datos simultáneas, cada una de ellas para una base de datos distinta. Sesiones diferentes pueden tener asociados diferentes. En la siguiente ilustración se muestra una instancia de servidor que actúa como testigo de dos sesiones de creación de reflejo de la base de datos con asociados diferentes.

Instancia de servidor que es testigo de 2 bases de datos

Una sola instancia de servidor también puede funcionar simultáneamente como testigo en unas sesiones y como asociado en otras. Sin embargo, en la práctica, las instancias de servidor suelen funcionar o como testigo o como asociado. Esto se debe a que los asociados requieren equipos complejos que tienen hardware suficiente para admitir una base de datos de producción, mientras que los testigos se pueden ejecutar en cualquier sistema de Windows disponible que admita SQL Server 2012.

Recomendaciones de software y hardware

Es muy recomendable que el testigo se encuentre en un equipo diferente de los asociados. Solo SQL Server 2005 Standard y las versiones posteriores, así como SQL Server 2005 Enterprise Edition y sus versiones posteriores admiten asociados de creación de reflejo de la base de datos. En cambio, los testigos también se admiten en SQL Server 2005 Workgroup y en versiones posteriores, así como en SQL Server 2005 Express Edition y versiones posteriores. Excepto durante una actualización de una versión anterior de SQL Server, todas las instancias de servidor de una sesión de creación de reflejo deben ejecutar la misma versión de SQL Server. Por ejemplo, se admite un testigo de SQL Server 2005 al actualizar desde una configuración de creación de reflejo de SQL Server 2005 pero no se puede agregar a una configuración de creación de reflejo existente o nueva de SQL Server 2008 o posterior.

Un testigo puede ejecutarse en cualquier sistema informático confiable que admita cualquiera de estas ediciones de SQL Server. No obstante, se recomienda que cualquier instancia del servidor que se utilice como testigo cumpla con los requisitos mínimos de configuración necesarios para la versión Standard de la versión de SQL Server que esté usando. Para obtener más información acerca de estos requisitos, vea Requisitos de hardware y software para instalar SQL Server 2012.

Rol del testigo en la conmutación automática por error

Durante la sesión de creación de reflejo de una base de datos, todas las instancias de servidor supervisan su estado de conexión. Si los asociados quedan desconectados entre sí, dependen del testigo para garantizar que únicamente uno de ellos sirve actualmente a la base de datos. Si un servidor reflejado sincronizado pierde su conexión con el servidor principal pero permanece conectado al testigo, se pondrá en contacto con el testigo para determinar si este último ha perdido la conexión con el servidor principal.

Si el servidor principal aún está conectado al testigo, no se produce la conmutación automática por error. Por el contrario, el servidor principal continúa sirviendo a la base de datos y, al mismo tiempo, acumula entradas del registro para enviarlas al servidor reflejado cuando los asociados vuelvan a conectarse.
Si el testigo también está desconectado del servidor principal, el servidor reflejado sabrá que la base de datos principal no está disponible. En este caso, el servidor reflejado inicia de inmediato la conmutación automática por error.
Si el servidor reflejado está desconectado del testigo y también del servidor principal, no se puede realizar la conmutación automática por error, independientemente del estado del servidor principal.

El requisito de que al menos dos de las instancias de servidor estén conectadas se denomina quórum. El quórum garantiza el servicio de la base de datos únicamente por parte de un asociado cada vez. Para obtener más información acerca del funcionamiento del quórum y su repercusión en una sesión, vea Quórum: cómo un testigo afecta a la disponibilidad de la base de datos (reflejo de base de datos).