Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Para admitir la conmutación automática por error, se debe configurar una sesión de reflejo de base de datos en modo de alta seguridad y también tener una tercera instancia de servidor, conocida como testigo. El testigo es una instancia opcional de SQL Server que permite al servidor espejo en una sesión de modo de alta seguridad reconocer si se debe iniciar una conmutación automática por error. A diferencia de los dos socios, el testigo no sirve a la base de datos. Admitir la conmutación automática por error es el único rol del testigo.
Nota:
En modo de alto rendimiento, el testigo puede afectar negativamente a la disponibilidad. Si un testigo está configurado para una sesión de espejo de bases de datos, el servidor principal debe estar conectado al menos a una de las otras instancias del servidor, el servidor reflejado o el testigo, o ambos. De lo contrario, la base de datos deja de estar disponible y forzar el servicio (con posible pérdida de datos) es imposible. Por lo tanto, para el modo de alto rendimiento, recomendamos encarecidamente que siempre mantenga el testigo en DESACTIVADO. Para obtener información sobre el impacto de un testigo en el modo de alta eficiencia, consulte Modos operativos de reflejo de base de datos.
En la ilustración siguiente se muestra una sesión en modo de alta seguridad con un testigo.
En este tema:
Uso de un testigo en varias sesiones
Una instancia de servidor específica puede actuar como testigo en sesiones simultáneas de reflejo de bases de datos, cada una para bases de datos diferentes. Las distintas sesiones pueden ser con diferentes socios. En la ilustración siguiente se muestra una instancia de servidor que es un testigo en dos sesiones de creación de reflejo de la base de datos con diferentes asociados.
Una instancia de servidor único también puede funcionar al mismo tiempo que un testigo en algunas sesiones y un asociado en otras sesiones. Sin embargo, en la práctica, una instancia de servidor normalmente funciona como testigo o socio. Esto se debe a que los asociados requieren equipos sofisticados que tienen suficiente hardware para admitir una base de datos de producción, mientras que el testigo puede ejecutarse en cualquier sistema Windows disponible que admita SQL Server 2014.
Recomendaciones de software y hardware
Se recomienda encarecidamente que el testigo resida en un equipo independiente de los socios. Los socios de reflejo de base de datos son admitidos solo por SQL Server Standard Edition y SQL Server Enterprise Edition. Los testigos, en cambio, también son compatibles con SQL Server Workgroup y con SQL Server Express. Excepto durante una actualización desde una versión anterior de SQL Server, las instancias de servidor en una sesión de reflejo deben ejecutarse todas en la misma versión de SQL Server. Por ejemplo, se admite un testigo de SQL Server 2008 al actualizar desde una configuración de creación de reflejo de SQL Server 2008, pero no se puede agregar a una configuración de creación de reflejo existente o nueva de SQL Server 2008 R2 o posterior.
Un testigo puede ejecutarse en cualquier sistema informático confiable que admita cualquier versión de SQL Server. Sin embargo, se recomienda que todas las instancias de servidor que se usen como testigo se correspondan con la configuración mínima necesaria para la versión estándar de SQL Server que está ejecutando. Para obtener más información sobre estos requisitos, vea Requisitos de hardware y software para instalar SQL Server 2014.
Papel del testigo en la conmutación automática por error
A lo largo de una sesión de creación de reflejo de la base de datos, todas las instancias del servidor supervisan su estado de conexión. Si los asociados se desconectan entre sí, dependen del testigo para asegurarse de que solo uno de ellos está atendiendo actualmente a la base de datos. Si un servidor reflejado sincronizado pierde su conexión con el servidor principal, pero permanece conectado al testigo, el servidor reflejado se pone en contacto con el testigo para determinar si el testigo ha perdido su conexión con el servidor principal:
Si el servidor principal sigue conectado al testigo, no se produce la conmutación automática por error. En su lugar, el servidor principal continúa sirviendo la base de datos mientras acumula registros del log para enviar al servidor reflejado cuando los servidores se vuelven a conectar.
Si el testigo también está desconectado del servidor principal, el servidor reflejado sabe que la base de datos principal no está disponible. En este caso, el servidor espejo inicia inmediatamente una conmutación automática por error.
Si el servidor reflejado está desconectado del testigo y también del servidor principal, la conmutación automática por error no es posible, independientemente del estado del servidor principal.
El requisito de que al menos dos de las instancias de servidor se conecten se conoce como cuórum. Quorum asegura que la base de datos solo pueda ser gestionada por un socio a la vez. Para obtener información sobre cómo funciona el cuórum y su impacto en una sesión, consulte Cuórum: Cómo afecta un testigo 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 eliminar el testigo
Véase también
Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server)
Modos de operación del reflejo de bases de datos
Cuórum: cómo un testigo afecta la disponibilidad de la base de datos (reflejo de la base de datos)
Posibles errores durante la creación de reflejo de la base de datos
Estados de creacion de reflejo (SQL Server)