Conmutación por error manual

Mantener la disponibilidad durante las actualizaciones

El administrador de la base de datos puede utilizar la conmutación por error manual para actualizar hardware o software sin sacrificar la disponibilidad. Para utilizar la creación de reflejo de la base de datos para las actualizaciones de software, el servidor reflejado y/o el sistema deben haber recibido ya las actualizaciones.

En la ilustración siguiente se muestra un ejemplo del uso de la conmutación por error manual para mantener la disponibilidad de la base de datos mientras se actualiza una instancia de servidor de bases de datos. Cuando se ha completado la actualización, un administrador puede realizar la conmutación por error para volver a la instancia de servidor original. Esto resulta útil cuando el administrador desea detener la sesión de creación de reflejos y utilizar el servidor reflejado en cualquier otro lugar. De este modo, se puede utilizar repetidamente una única instancia de servidor al actualizar una serie de instancias de servidor de bases de datos.

Condiciones requeridas para una conmutación por error manual

La conmutación por error manual exige establecer la seguridad de la transacción en FULL (es decir, modo de alta seguridad). Cuando los asociados están conectados y la base de datos ya está sincronizada, se admite la conmutación por error manual.

Cómo funciona la conmutación por error manual

La conmutación por error manual inicia la siguiente secuencia de acciones:

1. El servidor principal desconecta los clientes de la base de datos principal, envía el final del registro al servidor reflejado y, como preparación para cambiar a la función de reflejo, establece el estado de creación de reflejo en SYNCHRONIZING.

2. El servidor reflejado registra el número de secuencia de registro (LSN) de la última entrada de registro recibida desde el servidor principal como el LSN de la conmutación por error manual.

   [!NOTA]

   Para ver este LSN, seleccione la columna mirroring_failover_lsn en sys.database_mirroring (Transact-SQL).

3. Si algún registro espera en la cola rehecha, el servidor reflejado termina de poner al día la base de datos reflejada. La cantidad de tiempo que se necesita para ello depende de la velocidad del sistema, la carga de trabajo reciente y la cantidad de registro en la cola rehecha. Para un modo de funcionamiento sincrónico, el tiempo de conmutación por error se puede regular limitando el tamaño de la cola rehecha. Sin embargo, esto puede hacer que el servidor principal se ralentice para permitir que el servidor reflejado no se retrase.

   [!NOTA]

   Para conocer el tamaño actual de la cola rehecha, utilice el contador de rendimiento Cola rehecha en el objeto de rendimiento de creación de reflejo de la base de datos (para obtener más información, consulte Supervisar la creación de reflejo de la base de datos).

4. El servidor reflejado pasa a ser el nuevo servidor principal, y el que antes era el servidor principal se convierte en el nuevo servidor reflejado.

5. El nuevo servidor principal pone al día todas las transacciones no confirmadas y pone en línea su copia de la base de datos como la base de datos principal.

6. El servidor principal anterior asume la función reflejo, y la anterior base de datos principal se convierte en la base de datos reflejada. El nuevo servidor reflejado vuelve a sincronizar rápidamente la nueva base de datos reflejada con la nueva base de datos principal.

   [!NOTA]

   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.

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.

Vea también

Conceptos