• Artículo

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

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, consulte Operación asincrónica de creación de reflejo de la base de datos (Modo de alto rendimiento)

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

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 sofisticados con suficiente hardware para admitir una base de datos de producción, mientras que los testigos se pueden ejecutar en cualquier sistema Windows disponible que sea compatible con SQL Server 2008.

Recomendaciones de software y hardware

Es muy recomendable que el testigo se encuentre en un equipo diferente de los asociados. Sólo 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. Sin embargo, en SQL Server 2008 y versiones posteriores, un testigo de SQL Server 2005 sólo se admite cuando se actualiza desde una configuración de creación de reflejo de SQL Server 2005. Un testigo de SQL Server 2005 no se puede agregar a una configuración de creación de reflejo de SQL Server 2008 o posterior nueva o existente. El testigo debe ejecutarse en SQL Server 2008 o una versión 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 2008 R2. 

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.