Conmutación por error automática
La conmutación por error automática sólo se admite en sesiones de creación de reflejo de la base de datos que se ejecutan con un testigo en modo de alta seguridad (modo de alta seguridad con conmutación por error automática). En modo de alta seguridad con conmutación por error automática, una vez que se ha sincronizado la base de datos, si la base de datos principal deja de estar disponible, se produce la conmutación por error automática. La conmutación por error automática hace que el servidor reflejado asuma la función de servidor principal y ponga en conexión su copia de la base de datos como base de datos principal. El hecho de que se requiera la sincronización de la base de datos evita que se pierdan datos durante la conmutación por error, dado que cada transacción confirmada en la base de datos principal también se confirma en la base de datos reflejada.
Para que la conmutación por error automática mejore la confiabilidad, las bases de datos reflejada y principal deben residir en equipos diferentes.
La conmutación por error automática requiere las condiciones siguientes:
La sesión de creación de reflejo de la base de datos debe ejecutarse en modo de alta seguridad y debe poseer un testigo. Para obtener más información, vea Creación de reflejo sincrónico de la base de datos (modo de alta seguridad).
La sesión debe poseer un testigo.
La base de datos reflejada ya debe estar sincronizada. Esto garantiza que toda la parte del registro que se haya enviado al servidor reflejado se haya escrito en el disco.
El servidor principal ha perdido la comunicación con el resto de la configuración del reflejo de la base de datos, mientras que el servidor reflejado y el testigo conservan el quórum. Sin embargo, si todas las instancias de servidor pierden la comunicación, y el testigo y el servidor reflejado la recuperan después, no se produce la conmutación por error automática.
[!NOTA] Para obtener más información, vea Quórum: cómo un testigo afecta a la disponibilidad de la base de datos.
El servidor reflejado ha detectado la pérdida del servidor principal.
El modo en que el servidor reflejado detecta un error en el servidor principal depende de si éste es un error de software o de hardware. Para obtener más información, vea Posibles errores durante la creación de reflejo de la base de datos.
Si se cumplen las condiciones anteriores, la conmutación por error automática inicia la siguiente secuencia de acciones:
Si el servidor principal sigue en funcionamiento, cambiará el estado de la base de datos principal a DISCONNECTED y desconectará a todos los clientes de la base de datos principal.
Los servidores testigo y reflejado registran que el servidor principal no está disponible.
Si hay algún registro esperando en la cola de puesta al día, el servidor reflejado deja de poner al día la base de datos reflejada.
[!NOTA] La cantidad de tiempo que requiere la aplicación del registro depende de la velocidad del sistema, la carga de trabajo reciente y la cantidad de registro en la cola de puesta al día.
La base de datos reflejada anterior pasa a estar conectada como la nueva base de datos principal, y la recuperación limpia todas las transacciones no confirmadas revirtiéndolas lo más rápido posible. Los bloqueos aíslan esas transacciones.
Cuando el servidor principal anterior se reincorpora a la sesión, reconoce que su asociado de conmutación por error ahora tiene la función principal. El servidor principal anterior asume la función de reflejo, con lo que su base de datos pasa a ser la base de datos reflejada. El nuevo servidor reflejado sincroniza la nueva base de datos reflejada con la base de datos principal lo más rápido posible. Tan pronto como el nuevo servidor reflejado haya resincronizado las bases de datos, la conmutación por error vuelve a ser posible, pero en la dirección inversa.
En la siguiente ilustración se muestra una sola instancia de conmutación por error automática.
.gif "Conmutación por error automática")
Inicialmente, los tres servidores están conectados (es decir, la sesión tiene un quórum completo). Partner_A es el servidor principal y Partner_B es el servidor reflejado. Partner_A (o la base de datos principal en Partner_A) pasa a no estar disponible. El testigo y Partner_B reconocen que el servidor principal ya no está disponible y la sesión conserva el quórum. Partner_B se convierte en el servidor principal y hace que su copia de la base de datos esté disponible como la nueva base de datos principal. Finalmente, Partner_A se vuelve a conectar a la sesión y descubre que Partner_B posee ahora la función principal. Entonces, Partner_A asume la función de reflejo.
Tras la conmutación por error, los clientes deben volver a conectarse a la base de datos principal actual. Para obtener más información, vea Conectar clientes a una base de datos reflejada.
[!NOTA] Las transacciones que se han preparado mediante el Coordinador de transacciones distribuidas de Microsoft, pero que aún no están confirmadas en el momento de la conmutación por error, se consideran anuladas tras la conmutación por error de la base de datos.
Deshabilitar la conmutación por error automática mediante SQL Server Management Studio
Para deshabilitar la conmutación por error automática, abra la página Creación de reflejos de Propiedades de la base de datos, y cambie el modo de funcionamiento seleccionando una de las opciones siguientes:
- Alta seguridad sin conmutación por error automática (sincrónica)
En este modo, la base de datos sigue estando sincronizada y la conmutación por error manual sigue siendo posible. Para obtener más información, vea Creación de reflejo sincrónico de la base de datos (modo de alta seguridad). - Alto rendimiento (asincrónico)
En este modo, la base de datos reflejada podría ir un poco retrasada con respecto a la base de datos principal y la conmutación por error manual no es posible. Para obtener más información, vea Operación asincrónica de creación de reflejo de la base de datos (Modo de alto rendimiento).
Para cambiar el modo de funcionamiento
- Cómo configurar una sesión de creación de reflejo de la base de datos (SQL Server Management Studio)
Deshabilitar la conmutación por error automática mediante Transact-SQL
En cualquier punto de una sesión de creación de reflejo de la base de datos, el propietario de la base de datos puede deshabilitar la conmutación por error automática desactivando el testigo.
Para desactivar el testigo
[!NOTA] Desactivar el testigo mientras se mantiene la seguridad de las transacciones completa pone la sesión en modo de alta seguridad sin conmutación por error automática.
Vea también
Conceptos
Calcular la interrupción del servicio durante la conmutación de funciones
Posibles errores durante la creación de reflejo de la base de datos
Estados de creación de reflejo
Creación de reflejo sincrónico de la base de datos (modo de alta seguridad)