Creación de reflejo sincrónico de la base de datos (modo de alta seguridad)
Cuando la seguridad de las transacciones se define como FULL, la sesión de creación de reflejo de la base de datos se ejecuta en modo de alta seguridad y funciona de forma sincrónica después de una fase inicial de sincronización. En este tema se describen los detalles de las sesiones de creación de reflejo de la base de datos que están configuradas para el funcionamiento sincrónico. En este tema se presupone que está familiarizado con los conceptos básicos de las operaciones de creación de reflejo de la base de datos. Para obtener más información, vea Sesiones de creación de reflejo de la base de datos.
Para que una sesión funcione de forma sincrónica, el servidor reflejado debe sincronizar la base de datos reflejo con la base de datos principal. Cuando la sesión se inicia, el servidor principal comienza a enviar su registro activo al servidor reflejado. El servidor reflejado escribe todos los registros de entrada en el disco lo antes posible. Las bases de datos se sincronizan cuando todos los registros recibidos se escriben en el disco. Las bases de datos se sincronizan siempre y cuando los asociados permanezcan en comunicación.
[!NOTA] Utilice la clase de evento Database Mirroring State Change para supervisar los cambios de estado en una sesión de creación de reflejo de la base de datos. Para obtener más información, vea Database Mirroring State Change (clase de evento).
Cuando finaliza la sincronización, cada transacción confirmada en la base de datos principal también se confirma en el servidor reflejado, garantizando así la protección de los datos. Esto se consigue esperando la confirmación de una transacción en la base de datos principal hasta que el servidor principal recibe un mensaje del servidor reflejado indicando que ha reforzado el registro de transacciones en el disco. Tenga en cuenta que la espera de este mensaje aumenta la latencia de la transacción.
El tiempo necesario para la sincronización depende básicamente de la diferencia entre la base de datos reflejo y la base de datos principal en el momento de iniciar la sesión (diferencia calculada por el número de registros inicialmente recibidos del servidor principal), la carga de trabajo en la base de datos principal y la velocidad del sistema reflejo. Una vez sincronizada una sesión, el registro reforzado que aún debe rehacerse en la base de datos reflejada permanece en la cola de puesta al día. Para obtener más información, vea Sesiones de creación de reflejo de la base de datos.
En cuanto se sincroniza la base de datos reflejo, el estado de ambas copias de base de datos cambia a SYNCHRONIZED.
La operación sincrónica se mantiene de la siguiente manera:
- Al recibir una transacción de un cliente, el servidor principal escribe el registro para la transacción en el registro de transacciones.
- El servidor principal escribe la transacción en la base de datos y, al mismo tiempo, envía el registro al servidor reflejado. El servidor principal espera el reconocimiento del servidor reflejado antes de confirmar cualquiera de los elementos siguientes al cliente: una confirmación de transacción o una reversión.
- El servidor reflejado refuerza el registro en el disco y devuelve un reconocimiento al servidor principal.
- Al recibir el reconocimiento del servidor reflejado, el servidor principal envía un mensaje de confirmación al cliente.
El modo de alta seguridad protege los datos al hacer que sea necesario sincronizar los datos de dos lugares. Se garantiza que todas las transacciones confirmadas serán escritas en el disco del servidor reflejado.
Modo de alta seguridad sin conmutación por error automática
En la siguiente ilustración se muestra la configuración del modo de alta seguridad sin conmutación por error automática. La configuración sólo consta de dos asociados.
.gif "Asociados comunicándose sin ningún testigo")
Cuando los asociados están conectados y la base de datos ya está sincronizada, se admite la conmutación por error manual. Si la instancia de servidor reflejado se bloquea, la instancia de servidor principal no se ve afectada y queda expuesta (sin reflejar los datos). Si se pierde el servidor principal, el reflejo se suspende, pero el servicio puede forzarse manualmente en el servidor reflejado (con una posible pérdida de datos). Para obtener más información, vea Servicio forzado (con posible pérdida de datos).
Modo de alta seguridad con conmutación por error automática
La conmutación por error automática ofrece una alta disponibilidad al garantizar que se pueda servir a la base de datos incluso después de la pérdida de un servidor. La conmutación por error automática requiere que la sesión disponga de una tercera instancia de servidor, el testigo, que idealmente reside en un tercer equipo. En la siguiente ilustración se muestra la configuración de una sesión en modo de alta seguridad que admite la conmutación por error automática.
.gif "El testigo y los dos asociados de una sesión")
A diferencia de los dos asociados, el testigo no sirve a la base de datos. El testigo simplemente admite la conmutación por error automática al comprobar que el servidor principal se encuentre activo y en funcionamiento. El servidor reflejado inicia la conmutación por error automática sólo si éste y el testigo permanecen mutuamente conectados después de haberse desconectado del servidor principal.
Cuando se define un testigo, la sesión requiere quórum, una relación entre al menos dos instancias de servidor que permite que la base de datos pueda estar disponible. Para obtener más información, vea Quórum: cómo un testigo afecta a la disponibilidad de la base de datos y Conmutación por error automática. Para obtener más información, vea Testigo de creación de reflejo de la base de datos.
La conmutación por error automática requiere las condiciones siguientes:
- La base de datos ya está sincronizada.
- El error se produce mientras están conectadas las tres instancias de servidor, y el servidor testigo y el reflejado permanecen conectados.
La pérdida de un asociado tiene el siguiente efecto:
- Si la instancia de servidor principal no está disponible en las condiciones anteriores, se produce la conmutación por error automática. El servidor reflejado cambia a la función de principal y ofrece su base de datos como base de datos principal.
- Si el servidor principal no está disponible cuando estas condiciones no se cumplen, se puede forzar el servicio (con una posible pérdida de datos). Para obtener más información, vea Servicio forzado (con posible pérdida de datos).
- Si únicamente el servidor reflejado no está disponible, el principal y el testigo continúan.
Si la sesión pierde el testigo, el quórum requiere ambos asociados. Si uno de los asociados pierde el quórum, ambos lo pierden y la base de datos deja de estar disponible hasta que se restablece el quórum. El requisito de quórum garantiza que, en ausencia de un testigo, la base de datos no quede nunca expuesta, es decir, sin un reflejo.
[!NOTA] Si cree que el testigo va a permanecer desconectado durante bastante tiempo, se recomienda eliminarlo temporalmente de la sesión hasta que esté disponible.
Vea también
Conceptos
Sesiones de creación de reflejo de la base de datos
Quórum: cómo un testigo afecta a la disponibilidad de la base de datos
Configuración de Transact-SQL y modos de funcionamiento de la creación de reflejo de la base de datos
Otros recursos
Supervisar la creación de reflejo de la base de datos