Modos operativos de reflejo de bases de datos

En este tema se describen los modos operativos sincrónicos y asincrónicos para las sesiones de creación de reflejo de la base de datos.

Términos y definiciones

En esta sección se presentan algunos términos que son fundamentales para este tema.

Modo de alto rendimiento
La sesión de creación de reflejo de la base de datos funciona de forma asincrónica y usa solo el servidor principal y el servidor reflejado. La única forma de cambio de rol es el servicio forzado (con posible pérdida de datos).

modo Alta seguridad
La sesión de reflejo de la base de datos funciona de forma sincrónica y, opcionalmente, usa un testigo, junto con el servidor principal y el servidor espejo.

Seguridad de transacciones
Propiedad de base de datos específica de la creación de reflejo que determina si una sesión de creación de reflejo de la base de datos funciona de forma sincrónica o asincrónica. Hay dos niveles de seguridad: FULL y OFF.

Testigo
Para su uso solo con el modo de alta seguridad, una instancia opcional de SQL Server que permite al servidor reflejado reconocer si se debe iniciar una conmutación automática por error. A diferencia de los dos asociados de failover, el testigo no gestiona la base de datos. Admitir la conmutación automática por error es el único rol del testigo.

Reflejo asincrónico de bases de datos (modoHigh-Performance)

En esta sección se describe cómo funciona la creación de reflejo asincrónica de la base de datos, cuando es adecuado usar el modo de alto rendimiento y cómo responder si se produce un error en el servidor principal.

Cuando la seguridad de las transacciones se establece en OFF, la sesión de creación de reflejo de la base de datos funciona de forma asincrónica. La operación asincrónica solo admite un modo operativo de alto rendimiento. Este modo mejora el rendimiento a costa de la alta disponibilidad. El modo de alto rendimiento usa solo el servidor principal y el servidor reflejado. Los problemas en el servidor reflejado nunca afectan al servidor principal. En la pérdida del servidor principal, la base de datos reflejada se marca como DESCONECTADA, pero está disponible como standby en caliente.

El modo de alto rendimiento solo admite una forma de cambio de rol: servicio forzado (con posible pérdida de datos), que usa el servidor espejo como servidor de reserva. El servicio forzado es una de las posibles respuestas al error del servidor principal. Dado que es posible la pérdida de datos, debe tener en cuenta otras alternativas antes de forzar el servicio al reflejo. Para obtener más información, consulte Responder al fallo del principal en una sección posterior de este tema.

En la ilustración siguiente se muestra la configuración de una sesión mediante el modo de alto rendimiento.

En modo de alto rendimiento, en cuanto el servidor principal envía el registro para una transacción al servidor reflejado, el servidor principal envía una confirmación al cliente, sin esperar una confirmación del servidor reflejado. Las transacciones se confirman sin esperar a que el servidor reflejado escriba el registro en el disco. La operación asincrónica permite que el servidor principal se ejecute con una latencia de transacción mínima.

El servidor reflejado intenta mantenerse al día con los registros enviados por el servidor principal. Pero la base de datos espejo puede retrasarse un poco con respecto a la base de datos principal, aunque normalmente la brecha entre las bases de datos es pequeña. Sin embargo, la diferencia puede ser sustancial si el servidor principal está bajo una carga de trabajo pesada o el sistema del servidor espejo está sobrecargado.

¿Cuándo es adecuado el modo High-Performance?

El modo de alto rendimiento puede ser útil en un escenario de recuperación ante desastres en el que los servidores principal y reflejado están separados por una distancia significativa y donde no desea que los errores pequeños afecten al servidor principal.

Impacto de un testigo en el modo High-Performance

Si usa Transact-SQL para configurar el modo de alto rendimiento, siempre que la propiedad SAFETY esté establecida en OFF, se recomienda encarecidamente que la propiedad WITNESS también esté establecida en OFF. Un testigo puede coexistir con el modo de alto rendimiento, pero el testigo no proporciona ninguna ventaja e introduce riesgos.

Si el testigo está desconectado de la sesión cuando uno de los asociados deja de funcionar, la base de datos deja de estar disponible. Esto se debe a que, aunque el modo de alto rendimiento no requiera un testigo, si se establece uno, la sesión requiere un cuórum que consta de dos o más instancias de servidor. Si la sesión pierde quórum, no puede servir la base de datos.

Cuando un testigo se establece en una sesión en modo de alto desempeño, la aplicación del cuórum significa que:

• Si se pierde el servidor espejo, el servidor principal debe estar conectado también al testigo. De lo contrario, el servidor principal desconecta su base de datos hasta que el servidor testigo o el servidor reflejado se reincorpore a la sesión.

• Si se pierde el servidor principal, forzar el servicio al servidor de espejo requiere que el servidor de espejo esté conectado al testigo.

Responder al error del principal

Cuando el principal falla, el propietario de la base de datos tiene varias opciones, como se muestra a continuación:

• Mantenga la base de datos inaccesible hasta que el principal vuelva a estar disponible.

  Si la base de datos principal y su registro de transacciones están intactas, esta opción conserva todas las transacciones confirmadas a costa de la disponibilidad.

• Detenga la sesión de creación de reflejo de la base de datos, actualice manualmente la base de datos y, a continuación, inicie una nueva sesión de creación de reflejo de la base de datos.

  Si se pierde la base de datos principal, pero el servidor principal sigue en ejecución, intente realizar inmediatamente la copia de seguridad del final del registro en la base de datos principal. Si la copia de seguridad del final del registro se realiza correctamente, eliminar el reflejo puede ser la mejor alternativa. Después de quitar la creación de reflejo, puede restaurar el registro en la base de datos reflejada anterior, que conserva todos los datos.

  Nota:

  Si se produjo un error en la copia de seguridad del final del registro y no puede esperar a que se recupere el servidor principal, considere la posibilidad de forzar el servicio. Este tiene la ventaja de mantener el estado de sesión.

• Forzar el servicio (con posible pérdida de datos) en el servidor espejo.

  El servicio forzado es estrictamente un método de recuperación ante desastres y debe usarse con moderación. Forzar el servicio solo es posible si el servidor principal está inactivo, la sesión es asincrónica (la seguridad de transacciones está establecida en OFF) y la sesión no tiene ningún testigo (la propiedad WITNESS está establecida en OFF) o el testigo está conectado al servidor reflejado (es decir, tienen cuórum).

  Forzar el servicio hace que el servidor espejo asuma el rol de principal y sirva su copia de la base de datos a los clientes. Cuando se fuerza el servicio, se pierden los registros de transacciones que el servidor principal aún no ha enviado al servidor espejo. Por lo tanto, debe limitar el servicio forzado a situaciones en las que la pérdida de datos sea aceptable y la disponibilidad inmediata de la base de datos sea fundamental. Para obtener información sobre cómo funciona el servicio forzado y sobre los procedimientos recomendados para usarlo, vea Role Switching During a Database Mirroring Session (SQL Server).

Reflejo sincrónico de base de datos (modoHigh-Safety)

En esta sección se describe cómo funciona el reflejo sincrónico de la base de datos, incluidos los modos alternativos de alta seguridad (con conmutación automática de errores y sin conmutación automática de errores) y proporciona información sobre el rol del testigo en la conmutación automática de errores.

Cuando la seguridad de las transacciones se establece en FULL, la sesión de creación de reflejo de la base de datos se ejecuta en modo de alta seguridad y funciona sincrónicamente después de una fase de sincronización inicial. En esta sección se describen los detalles de las sesiones de creación de reflejo de la base de datos configuradas para la operación sincrónica.

Para lograr una operación sincrónica para una sesión, el servidor reflejado debe sincronizar la base de datos reflejada con la base de datos principal. Cuando se inicia la sesión, el servidor principal comienza a enviar su registro activo al servidor reflejado. El servidor espejo escribe todos los registros entrantes en el disco tan rápido como sea posible. Tan pronto como se hayan escrito todos los registros de registro recibidos en el disco, las bases de datos se sincronizan. Siempre que los asociados permanezcan en comunicación, las bases de datos permanecen sincronizadas.

Una vez finalizada la sincronización, todas las transacciones confirmadas en la base de datos principal también se confirman en el servidor reflejado, lo que garantiza la protección de los datos. Esto se logra esperando a confirmar una transacción en la base de datos principal, hasta que el servidor principal reciba un mensaje del servidor espejo que indica que ha protegido el registro de la transacción 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 distancia en que se encontraba la base de datos reflejada detrás de la base de datos principal al inicio de la sesión (medida por el número de registros recibidos inicialmente del servidor principal), la carga de trabajo en la base de datos principal y la velocidad del sistema reflejado. Una vez sincronizada una sesión, el registro consolidado que todavía no se ha rehecho en la base de datos espejo permanece en la cola de rehacer.

Tan pronto como se sincronice la base de datos reflejada, el estado de ambas copias de la base de datos cambia a SYNCHRONIZED.

La operación sincrónica se mantiene de la siguiente manera:

1. Al recibir una transacción de un cliente, el servidor principal escribe el registro de la transacción en el registro de transacciones.

2. El servidor principal escribe la transacción en la base de datos y, simultáneamente, envía el registro al servidor reflejado. El servidor principal espera una confirmación del servidor espejo antes de confirmar al cliente cualquiera de lo siguiente: un compromiso de transacción o una reversión.

3. El servidor espejo consolida el registro en el disco y devuelve una confirmación al servidor principal.

4. Al recibir la confirmación del servidor reflejado, el servidor principal envía un mensaje de confirmación al cliente.

El modo de alta seguridad protege los datos exigiendo que los datos se sincronicen entre dos lugares. Se garantiza que todas las transacciones confirmadas se escriban en el disco en el servidor espejo.

modo High-Safety sin conmutación automática por error

En la ilustración siguiente se muestra la configuración del modo de alta seguridad sin conmutación automática por error. La configuración consta solo de los dos socios.

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 del servidor de réplica se cae, la instancia del servidor principal no se ve afectada y opera de manera expuesta (es decir, sin replicar los datos). Si se pierde el servidor principal, se suspende el servidor espejo, pero el servicio se puede redirigir al servidor espejo (con posible pérdida de datos). Para obtener más información, vea Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server).

modo de High-Safety con conmutación automática por error

La conmutación automática por error proporciona alta disponibilidad asegurándose de que la base de datos sigue siendo atendida después de la pérdida de un servidor. La conmutación por error automática requiere que la sesión posea una tercera instancia del servidor, el testigo, que idealmente reside en un tercer equipo. En la ilustración siguiente se muestra la configuración de una sesión de modo de alta seguridad que admite la conmutación automática.

A diferencia de los dos socios, el testigo no sirve a la base de datos. El testigo simplemente soporta la conmutación por error automática comprobando si el servidor principal está operativo. El servidor espejo inicia la conmutación por error automática solo si el espejo y el testigo permanecen conectados entre sí después de que ambos se hayan desconectado del servidor principal.

Cuando se establece un testigo, la sesión requiere cuórum-una relación entre al menos dos instancias de servidor que permiten que la base de datos esté disponible. Para obtener más información, vea Testigo de reflejo de base de datos y Cuórum: Cómo un testigo afecta la disponibilidad de la base de datos (reflejo de base de datos).

La conmutación automática por error requiere las condiciones siguientes:

• La base de datos ya está sincronizada.

• El error se produce mientras las tres instancias del servidor están conectadas y el servidor testigo y el servidor espejo permanecen conectados.

La pérdida de un asociado tiene el siguiente efecto:

• Si el servidor principal deja de estar disponible bajo las condiciones mencionadas, ocurre un cambio automático de servidor. El servidor espejo cambia al rol de principal y ofrece su base de datos como base de datos principal.

• Si el servidor principal deja de estar disponible cuando no se cumplen esas condiciones, es posible forzar el servicio (con posible pérdida de datos). Para obtener más información, vea Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server).

• Si el único servidor de espejo deja de estar disponible, el servidor principal y el testigo continúan.

Si la sesión pierde su testigo, el cuórum requiere de ambos socios. Si alguno de los socios pierde quórum, ambos socios pierden el quórum y la base de datos deja de estar disponible hasta que se restablece el quórum. Este requisito de quórum garantiza que, en ausencia de un testigo, la base de datos nunca se ejecutará expuesta, es decir, sin estar replicada.

Configuraciones y modos operativos de reflejo de base de datos Transact-SQL

En esta sección se describe una sesión de reflejo de la base de datos en términos de la configuración de "ALTER DATABASE" y los estados de la base de datos reflejada y del testigo, si existe. La sección está destinada a los usuarios que administran la creación de reflejo de la base de datos principalmente o exclusivamente mediante Transact-SQL, en lugar de usar SQL Server Management Studio.

Cómo afecta la seguridad de las transacciones y el estado del testigo al modo operativo

El modo de funcionamiento de una sesión viene determinado por la combinación de su configuración de seguridad de transacciones y el estado del testigo. En cualquier momento, el propietario de la base de datos puede cambiar el nivel de seguridad de la transacción y puede agregar o quitar el testigo.

Seguridad de transacciones

La seguridad de transacciones es una propiedad específica del reflejo de base de datos que determina si una sesión de reflejo de la base de datos opera de manera sincrónica o asincrónica. Hay dos niveles de seguridad: FULL y OFF.

• SEGURIDAD COMPLETA

  La seguridad completa de las transacciones hace que la sesión funcione sincrónicamente en modo de alta seguridad. Si hay un testigo presente, una sesión admite la conmutación automática por error.

  Cuando se establece una sesión mediante instrucciones ALTER DATABASE, la sesión comienza con la propiedad SAFETY establecida en FULL; es decir, la sesión comienza en modo de alta seguridad. Una vez iniciada la sesión, puede agregar un testigo.

  Para obtener más información, vea Reflejo sincrónico de la base de datos (en modoHigh-Safety), anteriormente en este tema.

• SEGURIDAD DESACTIVADA

  Desactivar la seguridad de las transacciones hace que la sesión funcione de forma asincrónica, en modo de alto rendimiento. Si la propiedad SAFETY está establecida en OFF, la propiedad WITNESS también debe establecerse en OFF (valor predeterminado). Para obtener información sobre el impacto del testigo en modo de alto rendimiento, vea El estado del testigo, más adelante en este tema. Para obtener más información sobre cómo ejecutarse con seguridad de transacciones desactivada, consulte Creación de reflejo asincrónica de la base de datos ( modoHigh-Performance), anteriormente en este tema.

La configuración de seguridad de transacciones de la base de datos se registra en cada instancia en la vista de catálogo sys.database_mirroring en las columnas mirroring_safety_level y mirroring_safety_level_desc. Para obtener más información, vea sys.database_mirroring (Transact-SQL).

El propietario de la base de datos puede cambiar el nivel de seguridad de la transacción en cualquier momento.

Estado del testigo

Si se ha establecido un testigo, se requiere cuórum, por lo que el estado del testigo siempre es significativo.

Si existe, el testigo tiene uno de dos estados:

• Cuando el testigo está conectado a un asociado, se encuentra en el estado CONECTADO con respecto a él y tiene quórum con dicho asociado. En este caso, la base de datos puede estar disponible, incluso si uno de los asociados no está disponible.

• Cuando el testigo existe pero no está conectado a un asociado, el testigo se encuentra en el estado UNKOWN o DISCONNECTED en relación con ese asociado. En este caso, el testigo carece de cuórum con ese asociado y, si los asociados no están conectados entre sí, la base de datos deja de estar disponible.

Para obtener información sobre el cuórum, vea Cuórum: Cómo afecta un testigo a la disponibilidad de la base de datos (reflejo de base de datos).

El estado de cada testigo de una instancia de servidor se registra en la vista de catálogo de sys.database_mirroring en las columnas mirroring_witness_state y mirroring_witness_state_desc . Para obtener más información, vea sys.database_mirroring (Transact-SQL).

En la tabla siguiente se resume cómo el modo de funcionamiento de una sesión depende de su configuración de seguridad de transacciones y del estado del testigo.

¹ Si el testigo se desconecta, se recomienda establecer WITNESS OFF hasta que la instancia del servidor testigo esté disponible.

² Si un testigo está presente en modo de alto rendimiento, el testigo no participa en la sesión. Sin embargo, para que la base de datos esté disponible, al menos dos de las instancias del servidor deben permanecer conectadas. Por lo tanto, se recomienda mantener la propiedad WITNESS establecida en OFF en sesiones de modo de alto rendimiento. Para más información, vea Quorum: cómo un testigo afecta a la disponibilidad de la base de datos (Creación de reflejo de la base de datos).

Visualización de la configuración de seguridad y el estado del testigo

Para ver la configuración de seguridad y el estado del testigo para una base de datos, use la vista de catálogo de sys.database_mirroring . Las columnas pertinentes son las siguientes:

Por ejemplo, en el servidor principal o secundario, escriba:

SELECT mirroring_safety_level_desc, mirroring_witness_name, mirroring_witness_state_desc FROM sys.database_mirroring  

Para obtener más información sobre esta vista de catálogo, vea sys.database_mirroring (Transact-SQL).

Factores que afectan el comportamiento ante el fallo del servidor principal

En la tabla siguiente se resume el efecto combinado de la configuración de seguridad de transacciones, el estado de la base de datos y el estado del testigo en el comportamiento de una sesión de reflejo ante la pérdida del servidor principal.

Tareas relacionadas

• Agregar o reemplazar un testigo de creación de reflejo de la base de datos (SQL Server Management Studio)

• Establecer una sesión de creación de reflejo de la base de datos mediante la autenticación de Windows (SQL Server Management Studio)

• Agregar un testigo de reflejo de base de datos mediante la autenticación de Windows (Transact-SQL)

• Quitar el testigo de una sesión de creación de reflejo de la base de datos (SQL Server)

• Cambiar la seguridad de las transacciones en una sesión de espejo de la base de datos (Transact-SQL)

Véase también

Supervisar la creación de reflejo de la base de datos (SQL Server)
Testigo de creación de reflejo de la base de datos