Conmutación por error y modos de conmutación por error (Grupos de disponibilidad de Always On)

Se aplica a:SQL Server

En este artículo se describen la conmutación por error y los modos de conmutación por error para Always On grupos de disponibilidad de SQL Server.

Información general

En el contexto de un grupo de disponibilidad, el rol principal y el rol secundario de las réplicas de disponibilidad suelen poder intercambiarse mediante un proceso denominado conmutación por error. Hay tres formas de conmutación por error: conmutación por error automática (sin pérdida de datos), conmutación por error manual planeada (sin pérdida de datos) y conmutación por error manual forzada (con posible pérdida de datos), normalmente denominada conmutación por error forzada. Tanto la conmutación por error automática como la manual planificada conservan todos los datos. Un grupo de disponibilidad conmuta por error a nivel de réplica de disponibilidad. Es decir, un grupo de disponibilidad realiza la conmutación por error a una de sus réplicas secundarias (el destino actual de conmutación por error).

Durante la conmutación por error, el objetivo de conmutación por error asume el rol principal, recupera sus bases de datos y las pone en servicio como las nuevas bases de datos principales. La réplica principal anterior, cuando está disponible, cambia al rol secundario y sus bases de datos se convierten en bases de datos secundarias. Es posible que estos roles puedan alternarse entre sí (o cambiar a un destino de conmutación por error distinto) en respuesta a varios fallos o con fines administrativos.

Las formas de conmutación por error que admite una determinada réplica de disponibilidad están especificadas por la propiedad modo de conmutación por error. Para una réplica de disponibilidad determinada, los posibles modos de conmutación por error dependen del modo de disponibilidad de la réplica, como se indica a continuación:

• Las réplicas de confirmación sincrónica admiten dos opciones: automática o manual. El valor “automático” admite tanto la conmutación por error automática como la manual. Para evitar la pérdida de datos, la conmutación automática por error y la conmutación por error planeada requieren que el destino de conmutación por error sea una réplica secundaria de confirmación sincrónica con un estado de sincronización apropiado (esto indica que todas las bases de datos secundarias del destino de conmutación por error están sincronizadas con la base de datos principal correspondiente). Siempre que una réplica secundaria no cumpla ambas condiciones, solo admite la conmutación por error forzada. La conmutación por error forzada también se admite en las réplicas en un estado RESOLVING.

• Las réplicas de confirmación asincrónica solo admiten el modo de conmutación por error manual. Además, dado que nunca se sincronizan, solo admiten la conmutación por error forzada.

Cambios de SQL Server 2025

SQL Server 2025 presenta los siguientes cambios:

Conmutación automática rápida para problemas persistentes de estabilidad

En un entorno de grupo de disponibilidad Always On, el clúster de conmutación por error de Windows (WSFC) monitorea la integridad del grupo de disponibilidad y sus réplicas. Cuando se detecta un problema de salud en la réplica principal, WSFC desencadena una secuencia de acciones correctivas. De forma predeterminada, el WSFC reinicia el recurso del grupo de disponibilidad en la réplica actual. Si el WSFC no puede volver a activar el recurso, el WSFC transfiere el recurso del grupo de disponibilidad a otra réplica. Aunque esta secuencia de acciones correctivas es eficaz para los errores transitorios, puede provocar retrasos en la conmutación por error para los errores no transitorios.

El comportamiento de la conmutación por error de WSFC se controla mediante el parámetro RestartThreshold. De forma predeterminada, RestartThreshold se establece en 1 para un grupo de disponibilidad Always On, lo que significa que WSFC intenta reiniciar el recurso en el nodo actual antes de conmutar por error.

A partir de SQL Server 2025 (17.x), puede establecer el RestartThreshold de un grupo de disponibilidad Always On en 0, lo que indica al WSFC que haga una conmutación del recurso del grupo de disponibilidad inmediatamente cuando se detecta un problema de salud persistente. Esto es útil para escenarios en los que desea minimizar el tiempo de inactividad y asegurarse de que el grupo de disponibilidad siempre está disponible en una réplica saludable.

Hay una compensación obvia:

• Al establecer RestartThreshold en 1, el grupo de disponibilidad es más tolerante a errores transitorios y vuelve a estar en línea más rápido. Sin embargo, la conmutación por error y el tiempo de inactividad pueden prolongarse ante fallos persistentes.
• Al establecer RestartThreshold en 0, el grupo de disponibilidad es menos tolerante a fallas transitorias, por lo que podría realizar un failover innecesariamente. Sin embargo, la conmutación por error y la duración del tiempo de inactividad pueden ser más breves en caso de fallos persistentes.

Puede usar el Administrador de clústeres de conmutación por error o PowerShell para establecer para RestartThreshold un recurso de grupo de disponibilidad AlwaysOn.

Por ejemplo, para establecer el RestartThreshold en 0 para el grupo de disponibilidad llamado ag1, use el siguiente comando:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Para comprobar la configuración actual RestartThreshold , ejecute el siguiente comando:

Get-ClusterResource -Name "ag1" | Format-List *

Mejora del despacho de solicitudes de página asincrónicas

Cuando se conmuta por error un grupo de disponibilidad, cada réplica tiene que encontrar un punto de recuperación común al que sincronizarse. El punto de recuperación mantiene estable el grupo de disponibilidad para que pueda continuar aplicando cambios. Deshacer de rehacer forma parte de este proceso de sincronización. Las transacciones de deshacer y rehacer ocurren cuando una réplica secundaria debe revertir las transacciones para llegar al punto de recuperación común. La reversión de una operación rehacer es más común durante la conmutación por error en la recuperación ante desastres (DR) hacia una réplica asincrónica con FAILOVER_ALLOW_DATA_LOSS.

En determinadas situaciones, con una conmutación por error de recuperación ante desastres, a medida que la réplica secundaria pasa a ser la principal, la nueva principal experimenta latencia de red desde la principal original (ahora secundaria), lo que ralentiza el proceso de deshacer y rehacer en la nueva secundaria.

Para mejorar el proceso de deshacer de rehacer en este escenario, SQL Server 2025 (17.x) introduce una actualización del mecanismo de sincronización para que ahora el grupo de disponibilidad realice solicitudes de página de manera asincrónica y en lotes.

Tenga en cuenta lo siguiente.

• La mejora del mecanismo de sincronización está habilitada de forma predeterminada. Para deshabilitar la mejora y revertir al comportamiento predeterminado, habilite la marca de seguimiento 12348 en todas las réplicas de un grupo de disponibilidad que actualmente son secundarias o que podrían ser secundarias en el futuro.
• Si las réplicas del grupo de disponibilidad no tienen latencia de red, es posible que esta mejora no mejore la reversión de la repetición.

Las bases de datos cambian al estado de resolución después de un error

En raras ocasiones, una o varias bases de datos de un grupo de disponibilidad podrían permanecer en un estado No Sincronizando después de que un grupo de disponibilidad se desconecte durante un breve período de tiempo debido a una pérdida transitoria de quorum de WSFC, como por una desconexión temporal de la red o porque la mayoría de los nodos del clúster se reinicien. La actualización de la lógica de recuperación del grupo de disponibilidad introducida en SQL Server 2025 (17.x) mejora la tolerancia interna a este tipo de pérdida de cuórum de clúster y evita que las bases de datos del grupo de disponibilidad se bloqueen en el estado Not Synchronizing después de que el grupo de disponibilidad vuelva a estar en línea.

Términos y definiciones

Conmutación por error automática
Conmutación por error que se produce automáticamente al perderse la réplica principal. La conmutación por error automática solo se admite cuando la réplica principal actual y una réplica secundaria están configuradas con el modo de conmutación por error establecido en AUTOMATIC y la réplica secundaria está sincronizada actualmente. Si el modo de conmutación por error de la réplica principal o secundaria es MANUAL, la conmutación automática por error no puede ocurrir.

Conmutación por error manual programada (sin pérdida de datos)
La conmutación por error manual planeada, o conmutación por error manual, es una conmutación por error iniciada por un administrador de bases de datos, normalmente con fines administrativos. Una conmutación por error manual planificada solo se admite si tanto la réplica principal como la réplica secundaria están configuradas para el modo de confirmación sincrónica, y tanto la réplica principal como la réplica secundaria se encuentran sincronizadas (en el estado SYNCHRONIZED). Cuando la réplica secundaria de destino está sincronizada, puede realizarse una conmutación por error manual (sin pérdida de datos) aunque la réplica principal se haya bloqueado, ya que las bases de datos secundarias están listas para la conmutación por error. Un administrador de bases de datos inicia de forma manual una conmutación por error manual.

Conmutación por error forzada (con posible pérdida de datos)
Una conmutación por error que un administrador de base de datos puede iniciar cuando no hay ninguna réplica secundaria sincronizada con la réplica principal o la réplica principal no se está ejecutando y no hay ninguna réplica secundaria lista para la conmutación por error. La conmutación por error forzada conlleva riesgo de posible pérdida de datos y se recomienda estrictamente para la recuperación ante desastres. La conmutación por error forzada también se conoce como conmutación por error manual forzada, ya que solo puede iniciarse de forma manual. Esta es la única forma de conmutación por error admitida en el modo de disponibilidad con confirmación asincrónica.

Conmutación automática por error configurada

Dentro de un grupo de disponibilidad dado, par de réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica con conmutación por error automática, si existe. Un conjunto de conmutación automática por error solo tiene efecto si la réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.

Conjunto de conmutación por error con confirmación de compromiso sincrónica

Dentro de un grupo de disponibilidad dado, conjunto de dos o tres réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica, si lo hubiera. Un conjunto de conmutación por error con confirmación sincrónica solo surte efecto si las réplicas secundarias están configuradas en modo de conmutación por error manual y al menos una réplica secundaria se encuentra actualmente en estado SYNCHRONIZED con la réplica principal.

Conjunto completo de conmutación por error

En un grupo de disponibilidad determinado, el conjunto de todas las réplicas de disponibilidad cuyo estado operativo está actualmente en línea, independientemente del modo de disponibilidad y del modo de conmutación por error. Todo el conjunto de conmutación por error pasa a ser relevante cuando ninguna réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.

Descripción general de la conmutación por error

En la siguiente tabla se resumen las formas de conmutación por error admitidas en diferentes modos de disponibilidad y de conmutación por error. Para cada emparejamiento, el modo de disponibilidad efectivo y el modo de conmutación por error se determinan mediante la intersección de los modos de la réplica primaria junto con los modos de una o varias réplicas secundarias.

¹ Si emite un comando de conmutación por error forzada en una réplica secundaria sincronizada, la réplica secundaria se comporta igual que para una conmutación por error manual.

El período de tiempo que la base de datos no está disponible durante una conmutación por error depende del tipo de conmutación por error y su causa.

Conjuntos de conmutación por error

Las formas de conmutación por error posibles para un grupo de disponibilidad determinado se pueden considerar como conjuntos de conmutación por error. Un grupo de conmutación por error consta de la réplica principal y las réplicas secundarias que admiten una determinada forma de conmutación por error, como sigue:

• Conjunto de conmutación por error automática (opcional): Dentro de un grupo de disponibilidad determinado, un par de réplicas de disponibilidad (incluida la réplica principal actual) configuradas en modo de confirmación sincrónica con conmutación por error automática, si las hay. Un conjunto de conmutación automática por error solo tiene efecto si la réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.

• Conjunto de conmutación por error de confirmación sincrónica (opcional): Dentro de un grupo de disponibilidad dado, un conjunto de dos o tres réplicas de disponibilidad (incluida la réplica principal actual) que están configuradas para el modo de confirmación sincrónica, si lo hubiera. Un conjunto de conmutación por error con confirmación sincrónica solo surte efecto si las réplicas secundarias están configuradas en modo de conmutación por error manual y al menos una réplica secundaria se encuentra actualmente en estado SYNCHRONIZED con la réplica principal.

• Conjunto completo de conmutación por error: En un grupo de disponibilidad determinado, el conjunto de todas las réplicas de disponibilidad cuyo estado operativo es actualmente ONLINE, independientemente del modo de disponibilidad y el modo de conmutación por error. Todo el conjunto de conmutación por error pasa a ser relevante cuando ninguna réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.

Cuando se configura una réplica de disponibilidad con confirmación sincrónica y conmutación por error automática, la réplica de disponibilidad pasa a formar parte del conjunto de conmutación por error automática. Sin embargo, que la configuración surta efecto depende del nodo principal actual. Las formas de conmutación por error que son posibles en un momento dado dependen de qué grupos de conmutación por error estén vigentes en ese momento.

Por ejemplo, considere el caso de un grupo de disponibilidad con cuatro réplicas de disponibilidad, del siguiente modo:

El comportamiento de conmutación por error de cada réplica secundaria depende de cuál de las réplicas de disponibilidad es actualmente la réplica principal. Básicamente, para una réplica secundaria dada, el comportamiento de conmutación por error es el peor caso dada la réplica principal actual. En la ilustración siguiente se muestra cómo el comportamiento de conmutación por error de las réplicas secundarias varía en función de la réplica principal actual y si está configurado para el modo de confirmación asincrónica (solo con conmutación por error forzada) o el modo de confirmación sincrónica (con o sin conmutación automática por error).

Conmutación por error automática

Una conmutación por error automática hace que una réplica secundaria apta pase automáticamente al rol principal después de que la réplica principal deje de estar disponible. La conmutación por error automática es más adecuada cuando el nodo de WSFC que aloja la réplica principal está en la misma ubicación que el nodo que aloja la réplica secundaria. Esto se debe a que la sincronización de datos funciona mejor con una latencia de mensajes baja entre equipos y a que las conexiones de cliente pueden seguir siendo locales.

En esta sección:

• Condiciones necesarias para una conmutación automática por error

• Cómo funciona la conmutación automática por error

• Para habilitar la conmutación por error automática

Condiciones necesarias para una conmutación por error automática

La conmutación por error automática solo se produce en las siguientes condiciones:

• Ya existe un conjunto de conmutación por error automática. Este conjunto consta de una réplica principal y otra secundaria (el destino de conmutación por error automática), ambas configuradas en modo de confirmación sincrónica y establecidas para la conmutación por error AUTOMÁTICA. Si la réplica principal está establecida en conmutación por error MANUAL, no se puede producir la conmutación por error AUTOMÁTICA, aunque una réplica secundaria esté establecida en conmutación por error AUTOMÁTICA.

  Para más información, consulte Modos de disponibilidad (grupos de disponibilidad AlwaysOn).

• El destino de la conmutación por error automática tiene un estado de sincronización correcto (esto indica que cada base de datos secundaria del destino de la conmutación por error se sincroniza con la base de datos principal correspondiente).

  Sugerencia

  Los grupos de disponibilidad Always On supervisan el estado de ambas réplicas de un conjunto de conmutación por error automática. Si se produce un error en alguna de las réplicas, el estado del grupo de disponibilidad se establece en CRITICAL. Si se produce un error en la réplica secundaria, la conmutación automática no es posible porque el destino de la conmutación automática no está disponible. Si falla la réplica principal, el grupo de disponibilidad realizará una conmutación por error a la réplica secundaria. No existirá ningún destino de conmutación por error automática hasta que la réplica principal anterior se ponga en línea. De todas maneras, para garantizar la disponibilidad en el caso improbable de un fallo secuencial, se recomienda configurar una réplica secundaria diferente como destino de la conmutación por error automática.

  Para obtener más información, consulte Usar directivas de Always On para consultar el estado de un grupo de disponibilidad (SQL Server) y Cambiar el modo de conmutación por error de una réplica de disponibilidad (SQL Server).

• El clúster de conmutación por error de Windows Server (WSFC) tiene quórum. Para obtener más información, consulte Configuración de votación y modos de quórum de WSFC (SQL Server).

• La réplica principal no está disponible y se han cumplido los niveles de condición de conmutación por error definidos por la directiva de conmutación por error flexible. Para más información sobre los niveles de condición de conmutación por error, consulte Directiva de conmutación por error flexible para conmutación automática por error de un grupo de disponibilidad (SQL Server).

Cómo funciona la conmutación automática ante fallos

Una conmutación por error automática inicia la siguiente secuencia de acciones:

1. Si la instancia del servidor que hospeda la réplica principal actual sigue en ejecución, cambia el estado de las bases de datos principales a DISCONNECTED y desconecta todos los clientes.

2. Si hay registros del log pendientes en las colas de recuperación de la réplica secundaria de destino, la réplica secundaria aplica los registros del log restantes para completar el avance de las bases de datos secundarias.

   Nota:

   El tiempo necesario para aplicar el registro a una base de datos concreta depende de la velocidad del sistema, de la carga de trabajo reciente y de la cantidad de registros en la cola de recuperación.

3. La réplica secundaria anterior pasa a asumir el rol primario. Sus bases de datos se convierten en las bases de datos principales. La nueva réplica principal revierte las transacciones no confirmadas (fase de reversión de recuperación) lo más rápidamente posible. Los bloqueos aíslan las transacciones no confirmadas, permitiendo que se produzca la reversión en segundo plano mientras los clientes usan la base de datos. Este proceso no revierte las transacciones confirmadas.

   Hasta que se conecte una base de datos secundaria determinada, se marca brevemente como NOT_SYNCHRONIZED. Antes de que comience la recuperación tras la reversión, las bases de datos secundarias pueden conectarse a las nuevas bases de datos principales y pasar rápidamente al estado SYNCHRONIZED. El caso que mejor suele funcionar es aquel en el que hay una tercera réplica de confirmación sincrónica que permanece en el rol secundario después de la conmutación por error.

4. Posteriormente, cuando la instancia del servidor que hospeda la réplica principal anterior se reinicia, reconoce que otra réplica de disponibilidad posee el rol principal. La réplica principal anterior realiza la transición al rol secundario y sus bases de datos se convierten en bases de datos secundarias. La nueva réplica secundaria se conecta a la réplica principal actual y pone su base de datos al día con las bases de datos principales actuales lo más rápido posible. Tan pronto como la nueva réplica secundaria haya vuelto a sincronizar sus bases de datos, la conmutación por error vuelve a ser posible, pero en dirección inversa.

Para configurar la conmutación automática por fallo

Una réplica de disponibilidad se puede configurar para admitir la conmutación por error automática en cualquier momento.

Configurar la conmutación por error automática

1. Asegúrese de que la réplica secundaria esté configurada para utilizar el modo de disponibilidad de confirmación sincrónica. Para más información, consulte Cambiar el modo de disponibilidad de una réplica de disponibilidad (SQL Server).

2. Establezca el modo de conmutación por error a automático. Para más información, consulte Cambiar el modo de conmutación por error de una réplica de disponibilidad (SQL Server).

3. Si lo desea, puede cambiar la directiva de conmutación por error flexible del grupo de disponibilidad para especificar los tipos de fallos que pueden provocar una conmutación por error automática. Para más información, consulte Configurar la directiva de conmutación por error flexible para controlar las condiciones de la conmutación automática por error (grupos de disponibilidad AlwaysOn) y Directiva de conmutación por error para instancias de clústeres de conmutación por error.

Conmutación por error manual planificada (sin pérdida de datos)

Una conmutación por error manual hace que una réplica secundaria sincronizada pase al rol de principal después de que un administrador de bases de datos emite un comando de conmutación por error manual en la instancia del servidor que aloja la réplica secundaria de destino. Para admitir la conmutación por error manual, la réplica secundaria y la réplica principal actual se deben configurar en modo de confirmación sincrónica, si lo hubiera. Cada base de datos secundaria de la réplica de disponibilidad debe unirse al grupo de disponibilidad y sincronizarse con la base de datos principal correspondiente (es decir, la réplica secundaria se debe sincronizar). Esto garantiza que cada transacción confirmada en una base de datos principal anterior también se ha confirmado en la nueva base de datos principal. Por tanto, las nuevas bases de datos principales son idénticas a las bases de datos principales antiguas.

En la siguiente ilustración se muestran las fases de una conmutación por error planeada:

1. Antes de la conmutación por error, la instancia del servidor hospeda la réplica principal en Node01.

2. Un administrador de bases de datos inicia una conmutación por error planificada. El destino de la conmutación por error es la réplica de disponibilidad hospedada por la instancia de servidor en Node02.

3. El destino de la conmutación por error (en Node02) se convierte en la nueva réplica principal. Como se trata de una conmutación por error planeada, la réplica principal anterior se cambia al rol secundario durante la conmutación por error y pone inmediatamente sus bases de datos en línea como bases de datos secundarias.

En esta sección:

• Condiciones requeridas para una conmutación por error manual

• Cómo funciona la conmutación por error manual

• Mantener la disponibilidad durante las actualizaciones

Condiciones requeridas para una conmutación por error manual

Para admitir una conmutación por error manual, la réplica principal actual debe establecerse en modo de confirmación sincrónica y debe ser una réplica secundaria:

• Configurada para el modo de confirmación sincrónica.

• Sincronizada actualmente con la réplica principal.

Para realizar la conmutación por error manual en un grupo de disponibilidad, debe conectarse a la réplica secundaria que se va a convertir en la nueva réplica principal.

Cómo funciona la conmutación por error manual planeada

Una conmutación por error manual programada, que debe iniciarse en la réplica secundaria de destino, desencadena la siguiente secuencia de acciones:

1. Para asegurarse de que no se produzcan nuevas transacciones de usuario en las bases de datos primarias originales, el clúster de WSFC envía una solicitud a la réplica principal para que quede sin conexión.

2. Si hay algún registro de transacciones en espera en la cola de recuperación de alguna base de datos secundaria, la réplica secundaria termina de poner al día esa base de datos secundaria. La cantidad de tiempo necesaria depende de la velocidad del sistema, la carga de trabajo reciente y la cantidad de registros en la cola de recuperación. Para conocer el tamaño actual de la cola de recuperación, utilice el contador de rendimiento Cola de recuperación . Para obtener más información, vea SQL Server, Database Replica (SQL Server, réplica de base de datos).

   Nota:

   El tiempo de conmutación por error se puede regular limitando el tamaño de la cola de recuperación. Sin embargo, esto puede hacer que la réplica principal se ralentice para permitir que la réplica secundaria mantenga el ritmo.

3. La réplica secundaria se convierte en la nueva réplica principal y la réplica principal anterior se convierte en la nueva réplica secundaria.

4. La nueva réplica principal revierte las transacciones no confirmadas y pone sus bases de datos en línea como bases de datos principales. Todas las bases de datos secundarias se marcan brevemente como NOT SYNCHRONIZED hasta que se conectan y vuelven a sincronizar con las nuevas bases de datos principales. Este proceso no revierte las transacciones confirmadas.

5. Cuando la réplica principal anterior vuelve a estar en línea, toma el rol secundario y la base de datos principal anterior se convierte en la base de datos secundaria. La nueva réplica secundaria vuelve a sincronizar rápidamente las nuevas bases de datos secundarias con las bases de datos principales correspondientes.

   Nota:

   Tan pronto como la nueva réplica secundaria haya vuelto a sincronizar las bases de datos, la conmutación por error vuelve a ser posible, pero en sentido inverso.

Tras la conmutación por error, los clientes deben volver a conectarse a la base de datos primaria actual. Para más información, consulte Escuchas de grupo de disponibilidad, conectividad de cliente y conmutación por error de una aplicación (SQL Server).

Mantener la disponibilidad durante las actualizaciones

El administrador de base de datos para sus grupos de disponibilidad puede utilizar conmutaciones por error manuales para mantener la disponibilidad de la base de datos al actualizar el hardware o el software. Para utilizar un grupo de disponibilidad para actualizaciones de software, la instancia del servidor y/o el nodo del equipo que hospeda la réplica secundaria de destino deben haber recibido ya las actualizaciones. Para obtener más información, consulte Actualizar instancias de réplica de grupos de disponibilidad Always On.

Conmutación por error forzada (con posible pérdida de datos)

Forzar la conmutación por error de un grupo de disponibilidad (con posible pérdida de datos) es un método de recuperación ante desastres que permite usar una réplica secundaria como servidor en espera activa. Dado que forzar la conmutación por error puede conllevar a posibles pérdidas de datos, debe utilizarse con precaución y moderación. Recomendamos forzar la conmutación por error solo si debe restaurar inmediatamente el servicio en sus bases de datos de disponibilidad y está dispuesto a arriesgarse a perder datos. Para más información sobre los requisitos previos y las recomendaciones para forzar la conmutación por error y para ver un escenario de ejemplo que usa una conmutación por error forzada para recuperarse de un error grave, consulte Realizar una conmutación por error manual forzada de un grupo de disponibilidad (SQL Server).

En esta sección:

• Cómo funciona la conmutación por error forzada

• Riesgos de forzar la conmutación por error

• Por qué se requiere la conmutación por error después de forzar el quórum

• Seguimiento de la posible pérdida de datos

• Administrar la potencial pérdida de datos

Cómo funciona la conmutación por error forzada

Forzar la conmutación por error inicia una migración del rol principal a una réplica de destino cuyo rol está en el estado SECONDARY o RESOLVING. El destino de conmutación por error se convierte en la nueva réplica principal y pone inmediatamente sus copias de las bases de datos a disposición de los clientes. Cuando la réplica principal anterior está disponible, pasa al rol secundario y sus bases de datos se convierten en bases de datos secundarias.

Todas las bases de datos secundarias (incluidas las bases de datos principales anteriores cuando están disponibles) cambian al estado SUSPENDED. Según el estado anterior de sincronización de datos de una base de datos secundaria suspendida, esta puede ser adecuada para recuperar los datos ya confirmados que faltan de esa base de datos principal. En una réplica secundaria configurada para el acceso de solo lectura se pueden consultar las bases de datos secundarias para detectar manualmente los datos que faltan. A continuación, se pueden emitir instrucciones Transact-SQL en las nuevas bases de datos principales para realizar los cambios necesarios.

Riesgos de forzar la conmutación por error

Es esencial comprender que forzar la conmutación por error puede provocar la pérdida de datos. La pérdida de datos es posible porque la réplica de destino no puede comunicarse con la réplica principal y, por lo tanto, no puede garantizar que las bases de datos estén sincronizadas. Al forzar la conmutación por error se inicia una nueva bifurcación de recuperación. Dado que las bases de datos principales originales y las bases de datos secundarias están en diferentes ramificaciones de recuperación, cada una ahora contiene datos que no están presentes en la otra. Cada base de datos principal original contiene los cambios que aún no se enviaron desde su cola de envío a la anterior base de datos secundaria (el registro sin enviar); las anteriores bases de datos secundarias contienen los cambios que se producen después de que la conmutación por error fue forzada.

Si se fuerza la conmutación por error porque se ha producido un error en la réplica principal, la posible pérdida de datos depende de si se han enviado o no registros de transacciones a la réplica secundaria antes del error. En el modo de confirmación asincrónica, siempre existe la posibilidad de que se acumulen registros sin enviar. En modo de confirmación sincrónica, esto solo es posible hasta que las bases de datos secundarias estén sincronizadas.

En la siguiente tabla se resume la posibilidad de pérdida de datos en una base de datos determinada en la réplica a la que se fuerza la conmutación por error.

Las bases de datos secundarias solo hacen un seguimiento de dos bifurcaciones de recuperación, por lo que, si realiza varias conmutaciones por error forzadas, es posible que no pueda reanudar ninguna base de datos secundaria que hubiera iniciado la sincronización de datos tras la conmutación por error forzada anterior. Si esto ocurre, las bases de datos secundarias que no se pueden reanudar deberán quitarse del grupo de disponibilidad, restaurarlas al momento dado correcto y volver a unirse al grupo de disponibilidad. En este escenario, se puede observar el error 1408 con el estado 103 (error: 1408, gravedad: 16, estado: 103). Una restauración no funcionará entre varias bifurcaciones de recuperación; por tanto, asegúrese de realizar una copia de seguridad de registros después de realizar varias conmutaciones por error forzadas.

Por qué es necesaria la conmutación por error forzada después de forzar el quórum

Después de forzar el cuórum en el clúster de WSFC (cuórum forzado), debe realizar una conmutación por error forzada (con posible pérdida de datos) en cada grupo de disponibilidad. La conmutación por error forzada es necesaria porque el estado real de los valores del clúster WSFC puede haberse perdido. Evitar las conmutaciones por error normales después de un cuórum forzado es necesario debido a la posibilidad de que una réplica secundaria no sincronizada parezca estar sincronizada en el clúster WSFC reconfigurado.

Por ejemplo, considere un clúster WSFC que hospeda un grupo de disponibilidad en tres nodos: el nodo A hospeda la réplica principal y los nodos B y C hospedan una réplica secundaria. El nodo C se desconecta del clúster WSFC mientras la réplica secundaria local se sincroniza. Pero el Nodo A y el Nodo B conservan un quórum válido y el grupo de disponibilidad sigue en línea. En el nodo A, la réplica principal continúa aceptando actualizaciones y, en el nodo B, la réplica secundaria continúa sincronizándose con la réplica principal. La réplica secundaria del nodo C se desincroniza y se encuentra cada vez más retrasada respecto de la réplica principal. Sin embargo, debido a que el nodo C está desconectado, la réplica permanece incorrectamente en el estado SYNCHRONIZED.

Si se pierde el quórum y después se fuerza en el nodo A, el estado de sincronización del grupo de disponibilidad del clúster WSFC debería ser correcto y la réplica secundaria del nodo C debería mostrarse como UNSYNCHRONIZED. Sin embargo, si se fuerza el quórum en el nodo C, la sincronización del grupo de disponibilidad será incorrecta. El estado de sincronización del clúster se habrá revertido al estado que tenía cuando el nodo C estaba desconectado y la réplica secundaria del nodo C se mostraría incorrectamente como SYNCHRONIZED. Dado que las conmutaciones por error manuales planeadas garantizan la seguridad de los datos, no se les permite volver a poner en línea un grupo de disponibilidad después de forzar el cuórum.

Seguimiento de la posible pérdida de datos

Cuando el clúster WSFC tiene un quórum correcto, se puede calcular el potencial actual de pérdida de datos en las bases de datos. Para una réplica secundaria dada, el potencial actual de pérdida de datos depende de lo retrasadas que estén las bases de datos secundarias locales respecto de las bases de datos principales correspondientes. Debido a que la cantidad de retardo varía con el tiempo, se recomienda que realice un seguimiento periódico del potencial de pérdida de datos de las bases de datos secundarias no sincronizadas. El seguimiento del desfase implica comparar el último LSN de confirmación y la última hora de confirmación de cada base de datos principal y de sus correspondientes bases de datos secundarias, como sigue:

1. Conéctese a la réplica principal.

2. Consulte las columnas last_commit_lsn (LSN de la última transacción confirmada) y last_commit_time (hora de la última confirmación) de la vista de administración dinámica sys.dm_hadr_database_replica_states .

3. Compare los valores devueltos para cada base de datos principal y cada una de sus bases de datos secundarias. La diferencia entre sus últimos LSN de confirmación indican el tiempo de retardo.

4. Puede desencadenar una alerta cuando el tiempo de retardo en una base de datos o conjunto de base de datos supere el retardo máximo deseado durante un período de tiempo determinado. Por ejemplo, un trabajo que se ejecute cada minuto en cada base de datos principal puede realizar la consulta. Si la diferencia entre el valor de last_commit_time de una base de datos principal y cualquiera de sus bases de datos secundarias ha superado el objetivo de punto de recuperación (RPO) (por ejemplo, 5 minutos) desde la última vez que se ejecutó el trabajo, este puede generar una alerta.

Administrar la potencial pérdida de datos

Después de forzar una conmutación por error, se suspenden todas las bases de datos secundarias. Esto incluye las antiguas bases de datos principales, una vez que la réplica principal anterior vuelve a estar en línea y descubre que ahora es una réplica secundaria. Debe reanudar manualmente cada base de datos suspendida de forma individual en cada réplica secundaria.

Una vez que esté disponible la réplica principal anterior y en el supuesto de que sus bases de datos no estén dañadas, se puede intentar administrar la potencial pérdida de datos. El enfoque disponible para administrar la posible pérdida de datos depende de si la réplica principal original se ha conectado a la nueva réplica principal. Suponiendo que la réplica principal original pueda tener acceso a la nueva instancia principal, la reconexión se produce de forma automática y transparente.

La réplica principal original se ha vuelto a conectar

Normalmente, después de un fallo, cuando la réplica principal original se reinicia, vuelve a conectarse rápidamente a su réplica asociada. Al volver a conectarse, la réplica principal original se convierte en la réplica secundaria. Sus bases de datos se convierten en las bases de datos secundarias y entran en el estado SUSPENDED. Las nuevas bases de datos secundarias no se revertirán a menos que las reanude.

Sin embargo, las bases de datos suspendidas no son accesibles, por lo que no se pueden inspeccionar para evaluar qué datos se perderán si se reanudara una base de datos determinada. Por lo tanto, la decisión sobre si reanudar o quitar una base de datos secundaria depende de si está dispuesto a aceptar cualquier pérdida de datos, como se indica a continuación:

• Si una pérdida de datos es inaceptable, debe quitar las bases de datos del grupo de disponibilidad para protegerlas.

  El administrador de base de datos puede ahora recuperar las bases de datos principales anteriores e intentar recuperar los datos que se habrían perdido. Sin embargo, cuando una base de datos principal anterior está en línea, es divergente de la base de datos principal actual, por lo que el administrador de bases de datos debe hacer que la base de datos quitada o la base de datos principal actual no sea accesible para los clientes para evitar más divergencias de las bases de datos y evitar problemas de conmutación por error de cliente.

• Si la pérdida de datos es aceptable para sus objetivos empresariales, puede reanudar las bases de datos secundarias.

  Al reanudar una nueva base de datos secundaria se produce su reversión como primer paso en su sincronización. Si alguna entrada del registro estuviera esperando en la cola de envío en el momento del problema, se perderían las transacciones correspondientes, incluso si se hubieran confirmado.

La réplica principal original no se ha vuelto a conectar

Si puede impedir temporalmente que la réplica principal original se vuelva a conectar a través de la red a la nueva réplica principal, puede inspeccionar las bases de datos principales originales para evaluar qué datos se perderían si se reanudaran.

• Si la posible pérdida de datos es aceptable

  Permita que la réplica principal original se vuelva a conectar a la nueva réplica principal. La acción de volver a conectarse hace que las nuevas bases de datos secundarias se suspendan. Para iniciar la sincronización de datos en una base de datos, solo tiene que reanudarla. La nueva réplica secundaria descarta la bifurcación de recuperación original de esa base de datos, con lo que se pierden las transacciones que nunca se enviaron a la antigua réplica secundaria ni fueron recibidas por ella.

• Si la pérdida de datos es inaceptable

  Si la base de datos principal original contiene datos esenciales que se perderían si se reanudara la base de datos suspendida, puede preservar los datos de la base de datos principal original quitándola del grupo de disponibilidad. Esto hace que la base de datos entre en el estado RESTORING. Llegados a esta situación, se recomienda intentar realizar una copia de seguridad del final del registro de la base de datos quitada. Después, puede actualizar la base de datos principal actual (base de datos secundaria anterior) exportando los datos que desea proteger de la base de datos principal original e importándolos a la base de datos principal actual. Se recomienda realizar una copia de seguridad completa de la base de datos principal actualizada tan pronto como sea posible.

  A continuación, en la instancia del servidor que hospeda la nueva réplica secundaria, puede eliminar la base de datos secundaria suspendida y crear una nueva base de datos secundaria restaurando esta copia de seguridad (y una copia de seguridad de registro posterior) mediante RESTORE WITH NORECOVERY. Se recomienda retrasar la realización de copias de seguridad de registros adicionales de las bases de datos principales actuales hasta que se reanuden las bases de datos secundarias correspondientes.

Contenido relacionado

• Información general de los grupos de disponibilidad AlwaysOn (SQL Server)
• Modos de disponibilidad (grupos de disponibilidad AlwaysOn)
• Clústeres de conmutación por error de Windows Server (WSFC) con SQL Server
• Transacciones entre bases de datos y transacciones distribuidas para la creación de reflejo de la base de datos o grupos de disponibilidad AlwaysOn (SQL Server)
• Directiva de conmutación por error para instancias de clúster
• Directiva de conmutación por error flexible para conmutación automática por error de un grupo de disponibilidad (SQL Server)

Tareas relacionadas

Configuración del comportamiento de conmutación por error

• Cambiar el modo de disponibilidad de una réplica de disponibilidad (SQL Server)
• Cambiar el modo de conmutación por error de una réplica de disponibilidad (SQL Server)
• Configurar la directiva de conmutación por error flexible para controlar las condiciones de la conmutación automática por error (grupos de disponibilidad AlwaysOn)

Realizar una conmutación por error manual

• Realizar una conmutación por error manual planeada de un grupo de disponibilidad (SQL Server)
• Realización de una conmutación por error manual forzada de un grupo de disponibilidad (SQL Server)
• Usar el Asistente para grupos de disponibilidad de conmutación por error (SQL Server Management Studio)
• Administración de inicios de sesión y de trabajos para las bases de datos de un grupo de disponibilidad (SQL Server)

Configurar el quórum de WSFC

• Configurar la configuración NodeWeight del cuórum del clúster
• Ver la configuración de ponderación de nodo del cuórum del clúster
• Forzar el inicio de un clúster WSFC sin un quórum