Modos de funcionamiento de la creación de reflejo de la base de datos

Se aplica a:SQL Server

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

Términos y definiciones

En esta sección se presenta una serie de términos que son esenciales para este tema.

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

modo Alta seguridad
La sesión de duplicación de la base de datos opera de forma sincrónica y, opcionalmente, utiliza un testigo, además del servidor principal y el servidor espejo.

Seguridad de las 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 únicamente con el modo de alta seguridad, instancia opcional de SQL Server que habilita al servidor reflejado para que reconozca si se debe iniciar una conmutación automática por error. A diferencia de los dos asociados de conmutación por error, el testigo no sirve a la base de datos. El único rol del testigo es hacer posible la conmutación automática por error.

Operación asincrónica de creación de reflejo de la base de datos (Modo de alto rendimiento)

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

Si la seguridad de las transacciones está configurada 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 el modo operativo de alto rendimiento. Este modo mejora el rendimiento a costa de la alta disponibilidad. El modo de alto rendimiento utiliza solamente el servidor principal y el servidor reflejado. Los problemas del servidor reflejado nunca afectan al servidor principal. Al perderse el servidor principal, la base de datos reflejada se marca como DISCONNECTED, pero está disponible como base de datos en espera activa.

El modo de alto rendimiento solo admite una forma de cambio de rol: el servicio forzado (con posible pérdida de datos), que utiliza el servidor espejo como servidor en espera activa. El servicio forzado es una de las posibles respuestas a los errores del servidor principal. Dado que es posible la pérdida de datos, debe considerar otras alternativas antes de forzar el servicio en el servidor reflejado. Para obtener más información, consulte Respuesta al fallo del servidor principal, más adelante en este tema.

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

En el modo de alto rendimiento, en cuanto el servidor principal envía el registro de 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 la mínima latencia de transacciones.

El servidor reflejado intenta hacer frente a las entradas de registro enviadas por el servidor principal. Sin embargo, la base de datos reflejada puede retrasarse un poco con respecto a la base de datos principal, aunque la diferencia entra ambas suele ser pequeña. No obstante, la diferencia puede ser considerable si el servidor principal soporta una gran carga de trabajo o el sistema del servidor reflejado se encuentra sobrecargado.

En esta sección:

• Cuándo está indicado utilizar el modo de alto rendimiento

• El impacto de un testigo en el modo de alto rendimiento

• Responder ante los errores del servidor principal

Cuándo está indicado utilizar el modo de alto rendimiento

El modo de alto rendimiento puede resultar útil en un caso de recuperación de desastres en el que los servidores principal y reflejado se encuentran separados por una distancia considerable y no se desea que los pequeños errores afecten al servidor principal.

El impacto de Witness en el Modo de alto rendimiento

Si se utiliza 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 se establezca en OFF. Un testigo puede coexistir con el modo de alto rendimiento, pero no proporciona ventaja alguna y genera riesgo.

Si el testigo está desconectado de la sesión y uno de los asociados se bloquea, la base de datos no estará disponible. Esto es así porque, aun cuando el modo de alto rendimiento no necesita un testigo, si se establece uno, la sesión requiere un quórum compuesto de dos o más instancias de servidor. Si la sesión pierde el quórum, no puede servir a la base de datos.

Cuando se establece un testigo en una sesión en modo de alto rendimiento, la aplicación de quórum implica que:

• Si se pierde el servidor reflejado, el servidor principal se debe conectar al testigo. De lo contrario, el servidor principal mantiene su base de datos sin conexión hasta que el testigo o el servidor reflejado vuelven a unirse a la sesión.

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

Responder ante los errores del servidor principal

Si se produce un error en el servidor principal, el propietario de la base de datos tiene varias opciones:

• Dejar la base de datos inactiva hasta que el servidor principal vuelva a estar disponible.

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

• Detener la sesión de creación de reflejo de la base de datos, actualizar manualmente la base de datos y, después, iniciar una nueva sesión de creación de reflejo.

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

  Nota

  Si no se puede realizar la copia del final del registro y no puede esperar a que el servidor principal se recupere, considere la posibilidad de forzar el servicio, que ofrece la ventaja de mantener el estado de la sesión.

• Forzar la activación del servicio (con posible pérdida de datos) en el servidor espejo.

  El servicio forzado es estrictamente un método de recuperación de desastres y no se debe utilizar demasiado a menudo. Solo es posible forzar el servicio si el servidor principal está inactivo, la sesión es asincrónica (la seguridad de transacciones está configurada en OFF) y la sesión no tiene un testigo (la propiedad WITNESS está configurada en OFF) o el testigo se ha conectado al servidor reflejado (esto es, hay quórum).

  Al forzar el servicio, el servidor de reflejo asume el rol de principal y pone su copia de la base de datos a disposición de los clientes. Una vez forzado el servicio, los registros de transacciones que el servidor principal no haya enviado todavía al servidor reflejado se pierden. Por lo tanto, el servicio forzado debe limitarse a situaciones en las que sea aceptable la posible pérdida de datos y sea crucial la disponibilidad inmediata de la base de datos. Para obtener información sobre cómo funciona el servicio forzado y las prácticas recomendadas para su uso, vea Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server).

Creación de reflejo sincrónico de la base de datos (modo de alta seguridad)

En esta sección se describe cómo funciona la duplicación de la base de datos sincrónica, incluidos los modos alternativos de alta seguridad (con conmutación automática por error y sin ella), y se proporciona información sobre el papel del testigo en la conmutación automática por error.

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 esta sección 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.

Para que una sesión funcione de forma sincrónica, el servidor reflejado debe sincronizar la base de datos reflejada 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 espejo escribe en disco todas las entradas de registro entrantes lo más rápido 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.

Cuando finaliza la sincronización, cada transacción confirmada en la base de datos de 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 reflejada 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.

En cuanto se sincroniza la base de datos reflejada, el estado de ambas copias de 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 para la transacción en el registro de transacciones.

2. 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 un acuse de recibo del servidor espejo antes de confirmar al cliente cualquiera de las siguientes acciones: la confirmación de una transacción o una reversión.

3. El servidor reflejado refuerza el registro en el disco y devuelve un reconocimiento al servidor principal.

4. 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.

En esta sección:

• Modo de alta seguridad sin conmutación por error automática

• Modo de alta seguridad con conmutación automática por fallo

Modo de alta seguridad sin conmutación automática ante fallos

En la siguiente ilustración se muestra la configuración del modo de alta seguridad sin conmutación automática por error. La configuración consta de solo 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 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 en el servidor reflejado (con una 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 alta seguridad con conmutación automática por error

La conmutación automática por fallo proporciona alta disponibilidad al garantizar que la base de datos siga estando disponible incluso tras la caída de un servidor. La conmutación automática por error 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 automática por error.

A diferencia de los dos asociados, el testigo no sirve a la base de datos. El testigo simplemente admite la conmutación automática por error al comprobar que el servidor principal se encuentre activo y en funcionamiento. El servidor reflejado inicia la conmutación automática por error solo 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 Testigo de creación de reflejo de la base de datos y Quorum: cómo un testigo afecta a la disponibilidad de la base de datos (reflejo de la base de datos).

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

• 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 el servidor principal deja de estar disponible en las condiciones descritas anteriormente, se realiza una conmutación por error automática. El servidor espejo asume el rol de principal y ofrece su base de datos como la 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 Conmutación de roles durante una sesión de creación de reflejo de la base de datos (SQL Server).

• 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.

Configuraciones de Transact-SQL y modos de funcionamiento del reflejo de la base de datos

En esta sección se describe una sesión de creación de reflejo de la base de datos desde el punto de vista de la configuración de ALTER DATABASE y de los estados de la base de datos reflejada y del testigo, si existen. Esta sección está dirigida a los usuarios que administran la creación de reflejo de la base de datos principal o exclusivamente mediante Transact-SQL, en vez de mediante SQL Server Management Studio.

En esta sección:

• Cómo la seguridad de transacción y el estado del testigo afectan al modo de funcionamiento

• Ver la configuración de seguridad y el estado del testigo

• Factores que afectan al comportamiento en caso de pérdida del servidor principal

Cómo la seguridad de transacción y el estado del testigo afectan al modo de funcionamiento

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

En esta sección:

• Seguridad de transacciones

• Estado del testigo

Seguridad de las transacciones

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

• SEGURIDAD COMPLETA

  La seguridad total de las transacciones hace que la sesión funcione de forma sincrónica en modo de alta seguridad. Si existe un testigo, una sesión admite la conmutación automática por error.

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

  Para obtener más información, vea Creación de reflejo sincrónico de la base de datos (modo de alta seguridad), 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 estar establecida en OFF (el valor predeterminado). Para obtener información sobre el impacto del testigo en el modo de alto rendimiento, consulte El estado del testigo, más adelante en este tema. Para obtener más información sobre la ejecución con la seguridad de transacción desactivada, vea Operación asincrónica de creación de reflejo de la base de datos (Modo de alto rendimiento), anteriormente en este tema.

La configuración de seguridad de las transacciones de la base de datos se registra para cada asociado 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 las transacciones en cualquier momento.

Estado del testigo

Si se establece un testigo, es necesario que haya quórum, por lo que el estado del testigo será siempre significativo.

Si existe, el testigo tendrá uno de estos dos estados:

• Cuando el testigo está conectado a un asociado, el testigo tiene el estado CONNECTED en relación con el asociado y tiene quórum con ese asociado. En este caso, la base de datos puede estar disponible, incluso si alguno de los asociados no está disponible.

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

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

El estado de cada testigo en una instancia del servidor se registra en la vista de catálogo 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 las 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 hay un testigo en modo de alto rendimiento, no participará en la sesión. Sin embargo, para que la base de datos esté disponible, al menos dos de las instancias de servidor deben permanecer conectadas. Por lo tanto, recomendamos mantener la propiedad WITNESS configurada en OFF en las sesiones de modo de alto rendimiento. Para más informació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).

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

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

Por ejemplo, en el servidor principal o el servidor reflejado, 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 al comportamiento en caso de pérdida del servidor principal

En la tabla siguiente se resume el efecto combinado de la configuración de seguridad de las transacciones, el estado de la base de datos y el estado del testigo en el comportamiento de una sesión de creación de reflejo en caso de 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 creación de reflejo de la 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 transacción en una sesión de duplicación de la base de datos (Transact-SQL)

Consulte también

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