Conmutación por error manual
El documento está archivado y esta información podría estar obsoleta

Conmutación por error manual

La conmutación por error manual desconecta los clientes de la base de datos e invierte las funciones de los asociados. El modo de alta seguridad es el único que admite la conmutación por error manual.

ms191449.note(es-es,SQL.90).gifNota:
En este tema se supone que se está familiarizado con el modo de alta seguridad. Para obtener más información, vea Creación de reflejo sincrónico de la base de datos (modo de alta seguridad).

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.

ms191449.note(es-es,SQL.90).gifNota:
La creación de reflejo de base de datos podrá realizar una actualización gradual, pero no está garantizado, ya que no se conocen los cambios futuros.

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.

Conmutación por error manual planeada

La conmutación por error manual requiere que la seguridad de las transacciones se establezca en FULL y que la base de datos esté en estado SYNCHRONIZED.

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.
    ms191449.note(es-es,SQL.90).gifNota:
    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.
    ms191449.note(es-es,SQL.90).gifNota:
    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, vea 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 conexión 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.
    ms191449.note(es-es,SQL.90).gifNota:
    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.

Mostrar:
© 2016 Microsoft