Determinar por qué los cambios de la réplica principal no se reflejan en la réplica secundaria de un grupo de disponibilidad Always On

Se aplica a:SQL Server

La aplicación cliente finaliza una actualización en la réplica principal correctamente, pero una consulta a la réplica secundaria muestra que el cambio no se ha reflejado. En este caso, se presupone que el estado de sincronización de su disponibilidad es correcto. En la mayoría de casos, este comportamiento se resuelve pasados unos minutos.

Si los cambios aún no se reflejan en la réplica secundaria pasados unos minutos, puede haber un cuello de botella en el flujo de trabajo de sincronización. La ubicación del cuello de botella depende de si la réplica secundaria está configurada para confirmación sincrónica o asincrónica.

Confirmación sincrónica

Cada actualización realizada correctamente en la réplica principal ya se ha sincronizado con la réplica secundaria, o que los registros del log ya se han volcado para garantizar su persistencia en la réplica secundaria. Por lo tanto, el cuello de botella debe estar en el proceso de la fase de puesta al día que se produce después de que el registro se vacíe en la réplica secundaria.

Sin embargo, cuando se alcanza la fase de puesta al día, todas las cargas de trabajo de lectura de la réplica secundaria pasan por el aislamiento de instantáneas:

  • Transacciones de ejecución prolongada en la réplica principal

  • Fase de puesta al día en la réplica secundaria

Confirmación asincrónica

Puesto que la confirmación asincrónica da por confirmada una transacción en cuanto se escribe en el disco local, el cuello de botella puede estar en cualquier punto posterior:

  • Transacciones de larga duración en la réplica principal

  • Latencia o rendimiento de red

  • Confirmación del registro en la réplica secundaria

  • Fase de puesta al día en la réplica secundaria

En las siguientes secciones se describen las causas comunes de los cambios en la réplica principal que no se reflejan en la réplica secundaria para las consultas de solo lectura.

Transacciones activas de ejecución prolongada

Una transacción de larga duración en la réplica principal impide que las actualizaciones se lean en la réplica secundaria.

Explicación

Todas las cargas de trabajo de lectura de la réplica secundaria son consultas de aislamiento de instantáneas. En el aislamiento de instantánea, los clientes de solo lectura ven la base de datos de disponibilidad en la réplica secundaria tal como estaba en el punto inicial de la transacción activa más antigua del registro rehecho. Si una transacción no se ha confirmado desde hace horas, la transacción abierta impide que las consultas de solo lectura vean cualquier actualización nueva.

Diagnóstico y resolución

En la réplica principal, use DBCC OPENTRAN (Transact-SQL) para ver las transacciones activas más antiguas y vea si se pueden revertir. Cuando las transacciones activas más antiguas se han revertido y sincronizado en la réplica secundaria, las cargas de trabajo de lectura en la réplica secundaria pueden ver las actualizaciones en la base de datos de disponibilidad hasta el principio de la transacción activa que en aquel momento sea la más antigua.

La alta latencia de red o el bajo rendimiento de red producen una acumulación de registros en la réplica principal

La alta latencia de red o el bajo rendimiento pueden impedir que los registros se envíen a la réplica secundaria lo suficientemente rápido.

Explicación

La réplica principal activa el control de flujo en el envío del registro de transacciones cuando ha superado el número máximo permitido de mensajes no confirmados enviados a la réplica secundaria. Hasta que no se acepten algunos de estos mensajes, no se podrán enviar más bloques de registro a la réplica secundaria. Esta situación puede tener un impacto más grave en la posible pérdida de datos, lo que podría poner en peligro su objetivo de punto de recuperación (RPO).

Diagnóstico y resolución

Un valor alto de DMV log_send_queue_size puede indicar que los registros están siendo retenidos en la réplica principal. Dividir este valor por log_send_rate puede dar una estimación aproximada de cuánto tardarán los datos en ponerse al día en la réplica secundaria.

Además, también es útil comprobar los dos contadores de rendimiento SQL Server:Availability Replica > Flow Control Time (ms/sec) y SQL Server:Availability Replica Flow control/sec. Al multiplicar estos dos valores, puede ver cuánto tiempo se pasó en el último segundo esperando a que se liberara el control de flujo. Cuanto mayor sea el tiempo de espera del control de flujo, menor será la tasa de envío.

A continuación encontrará métricas útiles para diagnosticar el rendimiento y la latencia de red. Puede usar otras herramientas de Windows, como ping.exe, para evaluar el uso de la red.

  • DMV log_send_queue_size

  • DMV log_send_rate

  • Contador de rendimiento SQL Server:Database > Log Bytes Flushed/sec

  • Contador de rendimiento SQL Server:Database Mirroring > Send/Receive Ack Time

  • Contador de rendimiento SQL Server:Availability Replica > Bytes Sent to Replica/sec

  • Contador de rendimiento SQL Server:Availability Replica > Bytes Sent to Transport/sec

  • Contador de rendimiento SQL Server:Availability Replica > Flow Control Time (ms/sec)

  • Contador de rendimiento SQL Server:Availability Replica > Flow Control/sec

  • Contador de rendimiento SQL Server:Availability Replica > Resent Messages/sec

Para solucionar este problema, intente actualizar el ancho de banda de red o eliminar o reducir el tráfico de red innecesario.

Otra carga de trabajo de generación de informes impide la ejecución del subproceso redo

El subproceso de rehacer de la réplica secundaria está bloqueado e impedido de realizar cambios de lenguaje de definición de datos (DDL) debido a una consulta de solo lectura de larga duración. El subproceso de la fase de puesta al día debe desbloquearse para poder poner más actualizaciones a disposición de la carga de trabajo de lectura.

Explicación

En la réplica secundaria, las consultas de solo lectura adquieren bloqueos de estabilidad del esquema (Sch-S). Estos bloqueos Sch-S pueden impedir que el subproceso de la fase de puesta al día adquiera bloqueos de modificación del esquema (Sch-M) para hacer cambios en el lenguaje de definición de datos. Un hilo de redo bloqueado no puede aplicar los registros del log hasta que se desbloquee.

Diagnóstico y resolución

Cuando el subproceso de rehacer queda bloqueado, se genera un evento extendido denominado sqlserver.lock_redo_blocked. Además, puede consultar la DMV sys.dm_exec_request en la réplica secundaria para averiguar qué sesión está bloqueando el subproceso REDO y luego tomar medidas correctivas. La siguiente consulta devuelve el identificador de sesión de la carga de trabajo de informes que está bloqueando el subproceso de redo.

select session_id, command, blocking_session_id, wait_time, wait_type, wait_resource   
from sys.dm_exec_requests where command = 'DB STARTUP'

Puede dejar que la carga de trabajo de generación de informes finalice, en cuyo momento el subproceso de rehacer se desbloqueará, o puede desbloquear inmediatamente el subproceso de rehacer ejecutando el comando KILL (Transact-SQL) sobre el identificador de sesión que está bloqueando.

El subproceso de la fase de puesta al día se retrasa debido a la contención de recursos

Una gran carga de trabajo de informes en la réplica secundaria ha ralentizado el rendimiento de la réplica secundaria y el subproceso de la fase de puesta al día se ha retrasado.

Explicación

Al aplicar las entradas de registro en la réplica secundaria, el subproceso de rehacer lee las entradas de registro del disco de registro y, a continuación, para cada entrada de registro, accede a las páginas de datos para aplicar dicha entrada de registro. El acceso a la página puede estar limitado por la E/S (acceso al disco físico) si la página no está ya en la reserva de búferes. Si hay una carga de trabajo de informes enlazada a E/S, esta carga de trabajo compite por los recursos de E/S con el subproceso de la fase de puesta al día y puede ralentizar dicho subproceso. Esta situación no solo impide que otras cargas de trabajo de generación de informes vean datos actualizados, sino que también afecta al RTO.

Diagnóstico y resolución

Puede usar la siguiente consulta DMV para ver hasta qué punto el subproceso de la fase de puesta al día se ha retrasado, midiendo la diferencia entre last_redone_lsn y last_received_lsn.

select recovery_lsn, truncation_lsn, last_hardened_lsn, last_received_lsn,   
   last_redone_lsn, last_redone_time  
from sys.dm_hadr_database_replica_states

Si realmente el subproceso de la fase de puesta al día se retrasa, debe investigar la causa principal de la degradación del rendimiento en la réplica secundaria. Si hay contención de E/S con la carga de trabajo de informes, puede usar Resource Governor para controlar los ciclos de CPU que utiliza dicha carga de trabajo y, de ese modo, controlar indirectamente, hasta cierto punto, los ciclos de E/S consumidos. Por ejemplo, si la carga de trabajo de los informes está consumiendo un 10 % de la CPU, pero la carga de trabajo está enlazada a E/S, puede utilizar Resource Governor para limitar el uso de recursos de la CPU al 5 % y regular así la carga de trabajo de lectura. De esta forma, se reduce el impacto en la E/S.

Contenido relacionado

  • Last updated on