Database Mirroring Witness
Se aplica a:
SQL Server
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 del servidor, denominada 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 información sobre las repercusiones de un 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.
En este tema:
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.
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.
Recomendaciones de software y hardware
Es muy recomendable que el testigo se encuentre en un equipo diferente de los asociados. Los asociados de creación de reflejo de la base de datos solo se admiten en la edición SQL Server Standard y SQL Server Enterprise. Por el contrario, SQL Server Workgroup y SQL Server Express también admiten los testigos. 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 2008 (10.0.x) al actualizar desde una configuración de creación de reflejo de SQL Server 2008 (10.0.x), pero no se puede agregar a una configuración de creación de reflejo existente o nueva de SQL Server 2008 R2 (10.50.x) 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 sobre estos requisitos, vea Requisitos de hardware y software para instalar SQL Server 2016.
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 información sobre cómo funciona el cuórum y sus repercusiones en una sesión, vea Cuórum: cómo un testigo afecta a la disponibilidad de la base de datos (creación de reflejo de la base de datos).
Para agregar o quitar un testigo
Para agregar un testigo
Para quitar el testigo
Consulte también
Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server)
Database Mirroring Operating Modes
Quórum: cómo un testigo afecta a la disponibilidad de la base de datos (reflejo de base de datos)
Posibles errores durante la creación de reflejo de la base de datos
Estados de creacion de reflejo (SQL Server)
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de