Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn)

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

Dentro del contexto de un grupo de disponibilidad, el rol principal y el rol secundario de las réplicas de disponibilidad suelen ser intercambiables en 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 realiza la conmutación por error en el nivel de la réplica de disponibilidad. Es decir, un grupo de disponibilidad conmuta por error a una de sus réplicas secundarias (el destino de conmutación por erroractual).

Durante la conmutación por error, el destino de la conmutación por error asume el rol principal, recupera las bases de datos y las pone en línea 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. Estos roles podrían conmutarse repetidamente (o usar un destino de conmutación por error distinto) como respuesta a varios errores 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 valores: automático 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.

• Lasré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 la versión preliminar 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 realice un cambio por error en el recurso del grupo de disponibilidad inmediatamente cuando se detecte 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 la función de deshacer y rehacer para este escenario, la versión preliminar de SQL Server 2025 (17.x) introduce una actualización del mecanismo de sincronización, de modo que el grupo de disponibilidad ahora realiza solicitudes de página de forma 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 la versión preliminar de 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 en la pérdida de 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 planeada (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 planeada solo se admite si tanto la réplica principal como la secundaria se configuran en modo de confirmación sincrónica y si ambas se encuentran sincronizadas (en 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 base de datos inicia manualmente 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 puede sufrir pérdida de datos y está recomendada únicamente para la recuperación ante desastres. La conmutación por error forzada también se conoce como conmutación por error manual forzada porque solo se puede iniciar manualmente. Esta es la única forma de conmutación por error admitida en el modo de disponibilidad de confirmación asincrónica.

Conjunto de conmutación automática por error

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 confirmación sincrónica de conmutación por error

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 confirmación sincrónica de conmutación automática por error solo tiene efecto si las réplicas secundarias están configuradas para el modo de conmutación por error manual y al menos una réplica secundaria está actualmente en estado SYNCHRONIZED con la réplica principal.

Conjunto completo de conmutación por error

En un grupo de disponibilidad determinado, 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. El conjunto completo de conmutación por error es importante cuando no hay actualmente ninguna réplica secundaria en estado SYNCHRONIZED con la réplica principal.

Informació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 conjunto de conmutación por error consta de una réplica principal y varias réplicas secundarias que admiten una determinada forma de conmutación, de la manera siguiente:

• Conjunto de conmutación automática por error (opcional): Dentro de un grupo de disponibilidad dado, un 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 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 confirmación sincrónica de conmutación automática por error solo tiene efecto si las réplicas secundarias están configuradas para el modo de conmutación por error manual y al menos una réplica secundaria está 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. El conjunto completo de conmutación por error es importante cuando no hay actualmente ninguna réplica secundaria en estado SYNCHRONIZED con la réplica principal.

Al configurar una réplica de disponibilidad como confirmación sincrónica con conmutación por error automática, la réplica de disponibilidad forma parte de conjunto de conmutación automática por error. Sin embargo, que el conjunto tenga efecto dependerá de la réplica principal actual. Las formas de conmutación por error que son actualmente posibles en un momento determinado dependen de qué conjuntos de conmutación estén actualmente activos.

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 para cada réplica secundaria dependerá de qué réplica de disponibilidad sea 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 calificada realice la transición automática 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 apropiada cuando el nodo de WSFC que hospeda la réplica principal es local para el nodo que hospeda 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 requeridas 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 requeridas para una conmutación automática por error

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

• Ya existe un conjunto de conmutación por error automática. Este conjunto consta de una réplica principal y una secundaria (el destino de conmutación automática por error) que están configuradas para el modo de confirmación sincrónica y también para la conmutación AUTOMÁTICA por error. 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 AlwaysOn supervisan el estado de ambas réplicas de un conjunto de conmutación automática por error. 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 se produce un error en 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 más información, consulte Usar directivas de AlwaysOn para ver 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 del servicio de clústeres de conmutación por error (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 por error

Una conmutación automática por error 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 las entradas del registro están esperando en colas de recuperación en la réplica secundaria de destino, la réplica secundaria aplica las entradas del registro restantes para terminar la puesta al día de las bases de datos secundarias.

   Nota:

   La cantidad de tiempo que requiere la aplicación del registro a una base de datos dada depende de la velocidad del sistema, la carga de trabajo reciente y la cantidad de registro en la cola de cola de recuperación.

3. Las réplica secundaria anterior realiza la transición al rol principal. 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 la recuperación de reversión se inicie, las bases de datos secundarias pueden conectarse a las 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 detecta su base de datos en las bases de datos principales actuales lo más rápidamente 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 error

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

Para configurar la conmutación automática por error

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, también puede cambiar la directiva de conmutación por error flexible del grupo de disponibilidad para especificar los tipos de errores que pueden causar una conmutación automática por error. 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 planeada (sin pérdida de datos)

Una conmutación por error manual produce la transición de una réplica secundaria al rol principal después de que un administrador de bases de datos emita un comando de conmutación por error manual en la instancia del servidor que hospeda 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 planeada. 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 planeada, que se debe iniciar en la réplica secundaria de destino, inicia la siguiente secuencia de acciones:

1. Para asegurarse de que se producen transacciones de ningún usuario nuevo en las bases de datos principales originales, el clúster de WSFC envía una solicitud a la réplica principal para pasar a modo sin conexión.

2. Si un registro está esperando en la cola de recuperación de cualquier base de datos secundaria, la réplica secundaria finaliza las puesta al día de esa base de datos secundaria. 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 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 no se retrase.

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 dirección inversa.

Tras la conmutación por error, los clientes deben volver a conectarse a la base de datos principal 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, vea Actualización de instancias de la réplica del grupo de disponibilidad AlwaysOn.

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. Se recomienza que la conmutación por error solo se fuerce si es necesario restaurar el servicio en las bases de datos de disponibilidad inmediatamente y es aceptable el riesgo de perder algunos 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 la conmutación por error se convierte en la nueva réplica principal y sirve inmediatamente sus copias de las bases de datos a 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 de sincronización de datos anterior de una base de datos secundaria suspendida podría ser conveniente para recuperar los datos confirmados que faltan para 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, la acumulación del registro sin enviar siempre es una posibilidad. En modo de confirmación sincrónica, esto solo es posible hasta que las bases de datos secundarias estén sincronizadas.

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

Las bases de datos secundarias realizan el seguimiento solo en dos bifurcaciones de recuperación, por lo que, si se realizan varias conmutaciones por error forzadas, no podrá reanudarse ninguna de las bases de datos secundarias que comenzaron la sincronización de datos con 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é se requiere la conmutación por error 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 los nodos A y B conservan un quórum correcto 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 retardo implica comparar el Último LSN de confirmación y la Última hora de confirmación de cada base de datos principal y de sus bases de datos secundarias, de la forma siguiente:

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 y de forma individual cada una de las bases de datos suspendidas 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

Generalmente, después de un problema, cuando la réplica principal original se reinicia, se vuelve a conectar rápidamente a su asociado. 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 quita la bifurcación de recuperación original para esa base de datos, con lo que se pierden las transacciones que no se han enviado nunca a la réplica secundaria anterior o no se han recibido de 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 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 al menos una copia de seguridad de registros posterior) utilizando 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)
• Realizar una conmutación por error manual forzada de un grupo de disponibilidad (SQL Server)
• Usar el Asistente para grupo 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 los valores de NodeWeight de cuórum de clúster
• Ver la configuración de NodeWeight de cuórum de clúster
• Forzar el inicio de un clúster WSFC sin un quórum