Diferencias entre los modos de disponibilidad para un grupo de disponibilidad Always On

Se aplica a:SQL Server

En los grupos de disponibilidad Always On, el modo de disponibilidad es una propiedad de la réplica que determina si una réplica de disponibilidad dada puede ejecutarse en modo de confirmación sincrónica. Para cada réplica de disponibilidad, se debe configurar el modo de disponibilidad en modo de confirmación sincrónica, modo de confirmación asincrónica o modo de solo configuración.

Si la réplica principal está configurada para el modo de confirmación asincrónica, no espera a que ninguna réplica secundaria escriba registros de registro de transacciones entrantes en el disco (para proteger el registro).

Si una réplica secundaria está configurada para el modo de confirmación asincrónica, la réplica principal no espera a que esa réplica secundaria durabilice el registro. Si la réplica principal y una réplica secundaria determinada se configuran ambas para el modo de confirmación sincrónica, la réplica principal espera a que la réplica secundaria confirme que ha reforzado el registro (a menos que la réplica secundaria no pueda hacer ping a la réplica principal en el período de tiempo de espera de sesiónde la principal).

Modos de disponibilidad admitidos

Los grupos de disponibilidad AlwaysOn admiten tres modos de disponibilidad:

• Modo de confirmación asíncrona
• Modo de confirmación sincrónica
• Modo de solo configuración

Modo de confirmación asincrónica es una solución de recuperación ante desastres que funciona bien cuando las réplicas de disponibilidad están distribuidas a grandes distancias. Si cada réplica secundaria se ejecuta en modo de confirmación asincrónica, la réplica principal no espera a que ninguna de las réplicas secundarias confirme el registro. En su lugar, inmediatamente después de escribir el registro en el archivo de registro local, la réplica principal envía la confirmación de la transacción al cliente. La réplica principal se ejecuta con la mínima latencia de transacciones respecto a una réplica secundaria que se configura para el modo de confirmación asincrónica.

Si la principal actual está configurada para el modo de disponibilidad de confirmación asincrónica, confirma las transacciones de forma asincrónica para todas las réplicas secundarias, independientemente de su configuración de modo de disponibilidad individual.

Para obtener más información, consulte Modo de disponibilidad Asynchronous-Commit, más adelante en este artículo.

Elmodo de confirmación sincrónica establece prioridades de alta disponibilidad sobre el rendimiento, pero a costa de aumentar la latencia de las transacciones. En el modo de confirmación sincrónica, las transacciones no envían la confirmación de la transacción al cliente hasta que la réplica secundaria haya escrito de forma persistente el registro en disco. Cuando la sincronización de datos comienza en una base de datos secundaria, la réplica secundaria comienza a aplicar los registros entrantes desde la base de datos principal correspondiente. En cuanto se ha confirmado cada registro de eventos, la base de datos secundaria entra en el estado SYNCHRONIZED. A partir de entonces, la réplica secundaria confirma cada nueva transacción antes de que se escriba el registro en el archivo de registro local. Cuando todas las bases de datos secundarias de una réplica secundaria determinada están sincronizadas, el modo de confirmación sincrónica admite la conmutación por error manual y, opcionalmente, la conmutación por error automática.

Más adelante en este artículo, consulte modo de disponibilidad de Synchronous-Commit para obtener más información.

Modo solo de configuración se aplica a los grupos de disponibilidad que no están en un clúster de conmutación por error de Windows Server. Una réplica en modo de solo configuración no contiene datos de usuario. En el modo solo de configuración, la base de datos de réplica master almacena los metadatos de configuración del grupo de disponibilidad. Para más información, vea Alta disponibilidad y protección de datos para las configuraciones de grupo de disponibilidad.

En la ilustración siguiente se muestra un grupo de disponibilidad con cinco réplicas de disponibilidad. La réplica principal y una réplica secundaria se configuran para el modo de confirmación sincrónica con conmutación automática por error. Se configura otra réplica secundaria para el modo de confirmación sincrónica con conmutación por error manual planeada únicamente y se configuran dos réplicas secundarias para el modo de confirmación asincrónica, que solo admite la conmutación por error manual forzada (denominada normalmente conmutación por error forzada).

El comportamiento de sincronización y conmutación por error entre dos réplicas de disponibilidad depende del modo de disponibilidad de ambas réplicas. Por ejemplo, para que se produzca una confirmación sincrónica, tanto la réplica principal como la réplica secundaria deben configurarse para la confirmación sincrónica. Del mismo modo, para el failover automático, ambas réplicas deben configurarse para este proceso de forma automática. Por lo tanto, el comportamiento del escenario de implementación ilustrado anteriormente se puede resumir en la tabla siguiente, que explora el comportamiento con cada posible réplica principal:

Normalmente, el Nodo 04, como réplica con confirmación asíncrona, se despliega en un sitio de recuperación ante desastres. El hecho de que los nodos 01, 02 y 03 permanezcan en el modo de confirmación asincrónica tras la conmutación por error al nodo 04 ayuda a evitar una posible degradación del rendimiento en el grupo de disponibilidad debido a la alta latencia de red entre los dos sitios.

Modo asincrónico de disponibilidad de confirmación

En el modo de confirmación asincrónica, la réplica secundaria nunca se sincroniza con la réplica principal. Aunque una base de datos secundaria puede tener acceso a la base de datos principal correspondiente, cualquier base de datos secundaria podría retrasarse en cualquier momento. El modo de compromiso asincrónico puede ser útil en un escenario de recuperación ante desastres en el que la réplica primaria y la secundaria están separadas por una distancia significativa y donde no se quiere que pequeños errores afecten a la réplica primaria, o en situaciones donde el rendimiento es más importante que la protección sincronizada de datos. Además, dado que la réplica primaria no espera confirmaciones de la réplica secundaria, los problemas de la réplica secundaria nunca afectan a la réplica primaria.

Una réplica secundaria de confirmación asincrónica intenta hacer frente a las entradas de registro recibidas de la réplica principal. Pero las bases de datos secundarias con confirmación asincrónica siempre permanecen no sincronizadas y suelen presentar cierto retraso con respecto a las correspondientes bases de datos principales. Normalmente, la diferencia entre una base de datos secundaria de confirmación asincrónica y la base de datos principal correspondiente es pequeña. Pero la diferencia puede ser considerable si el servidor que hospeda la replicación secundaria está sobrecargado o la red es lenta.

El único tipo de conmutación por error que admite el modo de confirmación asincrónica es la conmutación por error forzada (con posible pérdida de datos). Forzar la conmutación por error es un último recurso reservado únicamente para situaciones en las que la réplica principal actual seguirá sin estar disponible durante un período prolongado y la disponibilidad inmediata de las bases de datos primarias es más importante que el riesgo de una posible pérdida de datos. El destino de conmutación por error debe ser una réplica cuyo estado del rol esté en SECONDARY o RESOLVING. El destino de la conmutación por error asume el rol principal y sus copias de las bases de datos se convierten en la base de datos principal. Cualquier base de datos secundaria restante, junto con las bases de datos principales anteriores, una vez que estén disponibles, se suspende hasta que se reanuden de forma manual e individualmente. En el modo de confirmación asincrónica, se pierden los registros de transacciones que la réplica principal original aún no había enviado a la réplica secundaria anterior. Esto significa que algunas o todas las nuevas bases de datos principales podrían carecer de las transacciones confirmadas recientemente. Para obtener más información acerca de cómo funciona la conmutación por error forzada y sobre las prácticas recomendadas para usarla, consulte Conmutación por error y modos de conmutación por error (grupos de disponibilidad Always On).

Modo de disponibilidad de confirmación sincrónica

En el modo de disponibilidad de confirmación sincrónica, después de unirse a un grupo de disponibilidad, una base de datos secundaria alcanza a la base de datos principal correspondiente y entra en el estado de SYNCHRONIZED. La base de datos secundaria permanece SYNCHRONIZED siempre que continúe la sincronización de datos. Esto garantiza que todas las transacciones confirmadas en una base de datos principal determinada se confirmen en la base de datos secundaria correspondiente. Cuando se sincronizan todas las bases de datos secundarias de una réplica secundaria determinada, el estado de mantenimiento de sincronización de la réplica secundaria en su conjunto es HEALTHY.

En esta sección:

• Factores que interrumpen la sincronización de datos
• Funcionamiento de la sincronización en una réplica secundaria
• Modo de confirmación sincrónica con solo conmutación por error manual
• Modo de confirmación sincrónica con conmutación automática por error

Factores que interrumpen la sincronización de datos

Una vez sincronizadas todas sus bases de datos, una réplica secundaria entra en el HEALTHY estado . La réplica secundaria sincronizada permanece en buen estado a menos que se produzca una de las siguientes acciones:

• Un retraso de la red, del equipo o una interferencia provoca que se agote el tiempo de espera de la sesión entre la réplica secundaria y la réplica principal.

  Nota:

  Para obtener información sobre la propiedad en tiempo de sesión de las réplicas de disponibilidad, consulte ¿Qué es un grupo de disponibilidad AlwaysOn?

• Se suspende la base de datos secundaria en la réplica secundaria. La réplica secundaria deja de estar sincronizada y su estado de mantenimiento de la sincronización se marca como NOT_HEALTHY. La réplica secundaria no puede volver a estar en buen estado hasta que la base de datos secundaria suspendida se reanude y se vuelva a sincronizar o se quite del grupo de disponibilidad.

• Agrega una base de datos principal al grupo de disponibilidad. Las réplicas secundarias sincronizadas previamente entran en el NOT_HEALTHY estado de estado de sincronización. Este estado indica que al menos una base de datos está en estado de NOT SYNCHRONIZING sincronización. Una réplica secundaria determinada no puede volver a estar HEALTHY hasta que se haya preparado una base de datos secundaria correspondiente en la réplica, se haya unido al grupo de disponibilidad y se sincronice con la nueva base de datos principal.

• Cambia la réplica principal o la réplica secundaria al modo de disponibilidad de confirmación asincrónica. Después de cambiar al modo de confirmación asincrónica, la réplica secundaria permanecerá en estado HEALTHY de estado de sincronización mientras continúe la sincronización de datos. Sin embargo, si solo se cambia la réplica principal al modo de confirmación asincrónica, la réplica secundaria de confirmación sincrónica entrará en el PARTIALLY_HEALTHY estado de salud de sincronización. Este estado indica que al menos una base de datos está en estado SYNCHRONIZING de sincronización, pero ninguna de las bases de datos está en estado NOT SYNCHRONIZING .

• Cambie cualquier réplica secundaria al modo de disponibilidad con confirmación sincrónica. Esto provoca que la réplica secundaria se marque como en el estado de salud de sincronización PARTIALLY_HEALTHY hasta que todas sus bases de datos estén en el estado de sincronización SYNCHRONIZED.

Funcionamiento de la sincronización en una réplica secundaria

En modo de confirmación sincrónica, después de que una réplica secundaria se una al grupo de disponibilidad y establezca una sesión con la réplica principal:

1. La réplica secundaria escribe registros de transacciones entrantes en el disco (hace persistente el registro).
2. La réplica secundaria envía un mensaje de confirmación a la réplica principal.

Después de que el registro firmado de la base de datos secundaria se haya sincronizado con el final del registro en la base de datos principal, el estado de la base de datos secundaria se establece en SYNCHRONIZED.

El tiempo necesario para la sincronización depende de la distancia en que se encontraba la base de datos secundaria detrás de la base de datos principal al inicio de la sesión. Esta diferencia se mide por el número de registros de registro recibidos inicialmente de la réplica principal, la carga que soporta la base de datos principal y la velocidad del anfitrión de la instancia de la réplica secundaria.

El proceso de transacción

En modo de confirmación sincrónica, las transacciones se confirman en ambas réplicas en este orden:

1. La réplica principal recibe una transacción de un cliente.

2. La réplica principal escribe el registro en el registro de transacciones y envía simultáneamente el registro a las réplicas secundarias.

   Una vez que se escribe un registro de registro en el registro de transacciones de la base de datos principal, la transacción solo se puede deshacer si hay una conmutación por error a una secundaria que no recibió el registro.

3. La réplica principal espera la confirmación de la réplica secundaria de confirmación sincrónica.

4. La réplica secundaria protege el registro y devuelve una confirmación a la réplica principal.

5. La réplica principal finaliza el procesamiento de confirmación y envía un mensaje de confirmación al cliente.

Tiempo de espera de confirmación sincrónica

Si una réplica secundaria de confirmación sincrónica agota el tiempo de espera sin confirmar que ha protegido el registro, se producen las siguientes acciones en el grupo de disponibilidad:

1. La réplica principal marca esa réplica secundaria como fallida.
2. El estado de la réplica secundaria cambia a DISCONNECTED.
3. El primario deja de esperar la confirmación.
4. El grupo de disponibilidad marca el estado de sincronización como NOT SYNCHRONIZING y el estado de réplica como NOT_HEALTHY.

Este comportamiento garantiza que una réplica secundaria de confirmación sincrónica fallida no impida el endurecimiento del registro en la réplica principal.

Cuando la réplica secundaria vuelva a estar en línea:

1. El estado de la réplica secundaria cambia a CONNECTED.
2. La réplica secundaria procesa la cola de envío de registros de la réplica principal.
3. El estado de sincronización pasa a SYNCHRONIZINGy el estado de la réplica a PARTIALLY_HEALTHY.

Una vez procesada la cola de envío de registros, el estado de sincronización se convierte en SYNCHRONIZEDy el estado de la réplica se convierte en HEALTHY.

El modo de confirmación sincrónica protege los datos exigiendo que estos estén sincronizados entre dos lugares, a costa de un ligero aumento de la latencia de las transacciones.

Modo de confirmación sincrónica solo con conmutación por error manual

Cuando estas réplicas están conectadas y la base de datos está sincronizada, se admite la conmutación por error manual. Si la réplica secundaria baja un nivel, la réplica principal no se ve afectada. La réplica principal se ejecuta expuesta si no existe ninguna SYNCHRONIZED réplica (es decir, sin enviar datos a ninguna réplica secundaria). Si se pierde la réplica principal, las réplicas secundarias entran en el estado RESOLVING, pero el propietario de la base de datos puede forzar una conmutación por error a la réplica secundaria (con posible pérdida de datos). Para más información, consulte Conmutación por error y modos de conmutación por error (grupos de disponibilidad AlwaysOn).

Modo de confirmación sincrónica con conmutación automática ante fallos

La conmutación automática por error proporciona alta disponibilidad al asegurar que la base de datos estará de nuevo disponible rápidamente después de la pérdida de la réplica principal. Para configurar un grupo de disponibilidad para la conmutación por error automática, debe configurar tanto la réplica principal actual como al menos una réplica secundaria en modo de confirmación sincrónica con conmutación por error automática. SQL Server 2019 (15.x) aumentó el número máximo de réplicas sincrónicas a 5, de las 3 que eran en SQL Server 2017 (14.x). Puede configurar este grupo de cinco réplicas para habilitar la conmutación automática por error dentro del grupo. Hay una réplica principal, además de cuatro réplicas secundarias sincrónicas.

Además, para que la conmutación automática por error sea posible en un momento dado, esta réplica secundaria se debe sincronizar con la réplica principal (es decir, todas las bases de datos secundarias están sincronizadas), y los clústeres de conmutación por error de Windows Server (WSFC) deben tener quórum. Si la réplica principal deja de estar disponible en estas condiciones, se produce una conmutación por error automática. La réplica secundaria cambia al rol de principal y ofrece su base de datos como la base de datos principal. Para obtener más información, consulte la sección "Conmutación automática por error" del artículo "Conmutación por error y Modos de conmutación por error (grupos de disponibilidad Always On)."

Latencia de datos en la réplica secundaria

Implementar el acceso de solo lectura a las réplicas secundarias resulta útil si las cargas de trabajo de solo lectura pueden tolerar cierta latencia en los datos. En las situaciones en las que la latencia de datos no es aceptable, considere la posibilidad de ejecutar cargas de trabajo de solo lectura en la réplica principal.

La réplica principal envía las entradas de registro de los cambios en la base de datos principal a las réplicas secundarias. En cada base de datos secundaria, un subproceso específico de repetición aplica los registros del log. En una base de datos secundaria de acceso de lectura, un cambio de datos determinado no aparece en los resultados de la consulta hasta que el registro de registro que contiene el cambio se ha aplicado a la base de datos secundaria y la transacción se ha confirmado en la base de datos principal.

Esto significa que hay cierta latencia, normalmente solo una cuestión de segundos, entre las réplicas principal y secundaria. No obstante, en casos excepcionales, por ejemplo, si los problemas de red reducen el rendimiento, la latencia puede ser importante. La latencia aumenta cuando se producen cuellos de botella de E/S y cuando se suspende el movimiento de los datos. Para supervisar el movimiento de datos suspendido, puede usar el panel del grupo de disponibilidad Always On (SQL Server Management Studio) o la vista de administración dinámica sys.dm_hadr_database_replica_states.

Para reducir la latencia en SQL Server 2025 (17.x) y versiones posteriores, puede reducir el tiempo (en milisegundos) que tarda la réplica principal en confirmar transacciones en la réplica secundaria. Para obtener más información, consulte Configuración del servidor: tiempo de confirmación del grupo de disponibilidad (ms).

Para cambiar el modo de disponibilidad y el modo de conmutación por error

• Cambio del modo de disponibilidad de una réplica dentro de un grupo de disponibilidad AlwaysOn
• Cambiar el modo de conmutación por error de una réplica dentro de un grupo de disponibilidad Always On

Para ajustar los votos de quórum

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

Para realizar una conmutación por error manual

• Realizar una conmutación por error manual planeada de un grupo de disponibilidad AlwaysOn (SQL Server)
• Realización de una conmutación por error manual forzada de un grupo de disponibilidad Always On (SQL Server)
• Usar el Asistente para la conmutación por error del grupo de disponibilidad (SQL Server Management Studio)

Ver los estados del grupo de disponibilidad, de la réplica de disponibilidad y de las bases de datos

• sys.dm_hadr_availability_group_states
• sys.dm_hadr_availability_replica_states
• sys.dm_hadr_database_replica_states

Contenido relacionado

• Guía de soluciones AlwaysOn de Microsoft SQL Server para lograr alta disponibilidad y recuperación ante desastres
• Blog del equipo Always On de SQL Server: el blog oficial del equipo de Always On de SQL Server
• ¿Qué es un grupo de disponibilidad Always On?
• Conmutación por error y modos de conmutación por error (grupos de disponibilidad de Always On)
• Clústeres de conmutación por error de Windows Server con SQL Server