Solución de problemas de puesta en cola de recuperación (rehacer) en un grupo de disponibilidad AlwaysOn

Resumen

Este artículo le ayuda a solucionar problemas de puesta en cola de recuperación (también denominado puesta al día) en una réplica secundaria de un grupo de disponibilidad AlwaysOn de SQL Server. Explica qué es la cola de recuperación, cómo comprobar el tamaño de la cola de redo y la tasa de redo, cómo interpretar los valores y cómo diagnosticar y corregir las causas comunes del retraso del redo, incluidos los hilos de redo bloqueados y el redo de un solo hilo.

Qué son las colas de recuperación

Los cambios realizados en la réplica principal de una base de datos de grupo de disponibilidad se envían a todas las réplicas secundarias del mismo grupo de disponibilidad. Después de que los cambios lleguen a una réplica secundaria, primero se escriben (protegidos) en el archivo de registro de transacciones de la base de datos del grupo de disponibilidad. Microsoft SQL Server, a continuación, usa la operaciónde recuperación o puesta al día para aplicar esos registros a los archivos de base de datos.

Si los cambios llegan y se confirman en el registro de transacciones más rápido de lo que pueden rehacerse, se forma una cola de recuperación. Esta cola es el conjunto de registros protegidos que aún no se aplican a la base de datos.

Síntomas y efectos de la puesta en cola de recuperación

Datos obsoletos en réplicas secundarias

Las cargas de trabajo de solo lectura que consultan réplicas secundarias podrían obtener datos obsoletos. Si se produce una cola de recuperación, los cambios recientes en la base de datos de la réplica principal todavía no son visibles en la secundaria cuando consultas esos mismos datos.

Los cambios llegan a la base de datos secundaria y se escriben en el archivo de registro de la base de datos, pero no son legibles hasta que la puesta al día los aplica a los archivos de datos.

Para obtener más información, consulte la sección "Latencia de datos en la réplica secundaria" de "Diferencias entre los modos de disponibilidad de un grupo de disponibilidad Always On".

Mayor tiempo de conmutación por error o RTO superado

El objetivo de tiempo de recuperación (RTO) es el tiempo de inactividad máximo de la base de datos que una organización puede tolerar y la rapidez con la que la organización puede recuperar el uso de la base de datos después de una interrupción. Si existe una cola de recuperación grande en una réplica secundaria cuando se produce una conmutación por error, la operación de rehacer en la nueva réplica principal puede tardar más de lo establecido por el RTO. Una vez finalizada la fase de puesta al día, la base de datos pasa al rol principal y refleja el estado que existía antes de la conmutación por error. Un tiempo de rehacer más largo retrasa la rapidez con la que se reanuda la producción.

Las herramientas de diagnóstico notifican un grupo de disponibilidad incorrecto

Cuando la puesta al día de la cola es significativa, el panel AlwaysOn de SQL Server Management Studio (SSMS) podría mostrar el grupo de disponibilidad como incorrecto.

Comprobar la puesta en cola de recuperación

La cola de recuperación es una métrica para cada base de datos. Puede comprobarlo desde el panel AlwaysOn en la réplica principal o consultando la vista de administración dinámica (DMV) sys.dm_hadr_database_replica_states en la réplica principal o secundaria. Los contadores de Monitor de rendimiento también informan sobre el tamaño de la cola de recuperación y la tasa de rehacer. Compruebe esos contadores en la réplica secundaria.

Las siguientes secciones describen métodos para supervisar activamente la cola de recuperación de la base de datos del grupo de disponibilidad.

Consultar sys.dm_hadr_database_replica_states

La sys.dm_hadr_database_replica_states DMV informa de una fila para cada base de datos de grupo de disponibilidad. La redo_queue_size columna muestra el tamaño de la cola de recuperación en kilobytes. Para supervisar la tendencia en el tamaño de la cola de recuperación cada 30 segundos, configure una consulta como la siguiente. Ejecútelo en la réplica principal. Usa el predicado is_local=0 para informar sobre los datos de la réplica secundaria, cuando redo_queue_size y redo_rate sean pertinentes.

WHILE 1=1
BEGIN
SELECT drcs.database_name, ars.role_desc, drs.redo_queue_size, drs.redo_rate,
ars.recovery_health_desc, ars.connected_state_desc, ars.operational_state_desc, ars.synchronization_health_desc, *
FROM sys.dm_hadr_availability_replica_states ars JOIN sys.dm_hadr_database_replica_cluster_states drcs ON ars.replica_id=drcs.replica_id
JOIN sys.dm_hadr_database_replica_states drs ON drcs.group_database_id=drs.group_database_id
WHERE ars.role_desc='SECONDARY' AND drs.is_local=0
waitfor delay '00:00:30'
END

Este es el aspecto de la salida.

Captura de pantalla de la salida de la consulta notifica los datos de la réplica secundaria donde redo_queue_size y redo_rate son pertinentes.

Revise la cola de recuperación en el panel Always On

Para revisar la cola de recuperación, siga estos pasos:

  1. En SSMS Explorador de objetos, seleccione y mantenga presionado (o haga clic con el botón derecho) en un grupo de disponibilidad para abrir el menú contextual.

  2. Seleccione Mostrar panel.

    Las bases de datos del grupo de disponibilidad aparecen al final, y se muestran algunos datos de cada una. Tamaño de la cola de rehacer (KB) y Tasa de rehacer (KB/sec) no aparecen de forma predeterminada, pero puedes agregarlos a la vista, como se muestra en el siguiente paso.

  3. Para agregar estos contadores, seleccione y mantenga presionado (o haga clic con el botón derecho) en el encabezado situado encima de los informes de base de datos y, a continuación, elija las columnas que desea mostrar.

  4. Para agregar Tamaño de la cola de rehacer (KB) y Tasa de rehacer (KB/s), mantenga pulsado (o haga clic con el botón derecho en) el encabezado resaltado en rojo en la siguiente captura de pantalla.

    Captura de pantalla que muestra cómo agregar los contadores Redo Queue Size (KB) y Redo Rate (KB/sec).

    De forma predeterminada, el panel de Always On actualiza automáticamente el tamaño de la cola de rehacer (KB) y la tasa de rehacer (KB/sec) cada 60 segundos.

    Captura de pantalla que muestra los contadores de actualización establecidos en cada 60 segundos.

Revise la cola de recuperación en Monitor de rendimiento

Cada réplica secundaria y base de datos tiene su propio tamaño de cola de recuperación. Para revisar la cola de recuperación de una base de datos de grupo de disponibilidad, siga estos pasos:

  1. Abra el Monitor de rendimiento en la réplica secundaria.

  2. Seleccione el botón Agregar (contador).

  3. En Contadores disponibles, seleccione SQLServer:Réplica de base de datos y, a continuación, seleccione los contadores Cola de recuperación y Bytes rehechos/s.

  4. En el cuadro de lista Instancia, seleccione la base de datos del grupo de disponibilidad que desea supervisar la cola de recuperación.

  5. Seleccione Agregar>Aceptar.

    Así podría verse un aumento de las colas de recuperación.

    Captura de pantalla que muestra un aumento en la cola de recuperación.

Interpretación de los valores de puesta en cola de recuperación

En esta sección se explica cómo interpretar los valores de puesta en cola de recuperación recopilados en la sección anterior.

Cuando la cola de recuperación es un problema

Un valor de cola de recuperación de 0 significa que no hay trabajo pendiente de puesta al día en el momento del informe. En un entorno de producción con mucha actividad, la cola de recuperación a menudo muestra un valor distinto de cero incluso cuando el grupo de disponibilidad está en buen estado. Durante la producción típica, espere que el valor fluctúe entre 0 y un valor distinto de cero.

Si la cola de recuperación crece con el tiempo, investigue más a fondo. El crecimiento indica que algo ha cambiado. Cuando se ve un crecimiento repentino, las siguientes medidas son útiles para solucionar problemas:

  • Tasa de repetición del registro (KB/s) (panel de Always On)
  • redo_rate en sys.dm_hadr_database_replica_states

Establecimiento de tasas de recuperación de línea base

Durante el funcionamiento correcto de Always On, supervise la tasa de rehacer en las bases de datos más activas de sus grupos de disponibilidad. Registre las tasas de captura durante el horario habitual de actividad y durante las ventanas de mantenimiento, cuando las transacciones grandes (como las reconstrucciones de índices o los procesos ETL) generan un mayor volumen de procesamiento. Compare esos valores de referencia cuando observe un aumento en la cola de recuperación para identificar qué ha cambiado. La carga de trabajo puede ser mayor de lo habitual o la tasa de rehacer podría ser inferior a la esperada, lo que necesita una investigación adicional.

Cuenta del volumen de carga de trabajo

Las cargas de trabajo grandes (como una instrucción UPDATE en un millón de filas, la reconstrucción de un índice en una tabla de 1 TB o un lote de ETL que inserta millones de filas) suelen provocar cierto aumento de la cola de recuperación, ya sea de inmediato o con el tiempo. Este crecimiento se espera cuando se realizan muchos cambios repentinamente en la base de datos del grupo de disponibilidad.

Diagnosticar la cola de recuperación

Después de identificar la cola de recuperación para una base de datos concreta del grupo de disponibilidad de una réplica secundaria, conéctese a la réplica secundaria y, a continuación, consulte sys.dm_exec_requests para comprobar wait_type y wait_time para los subprocesos de recuperación. Busca una frecuencia alta de uno o varios tipos de espera y tiempos de espera grandes para esos tipos de espera. La siguiente consulta de ejemplo se ejecuta cada cinco segundos e informa de los tipos de espera y los tiempos de espera de la base de datos agdbdel grupo de disponibilidad :

WHILE (1=1)
BEGIN
SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')
waitfor delay '00:00:05.000'
END

Importante

Para obtener un resultado significativo sobre los tipos de espera, la cola de recuperación debe estar creciendo cuando recopile estos datos mediante uno de los métodos descritos anteriormente.

En el ejemplo siguiente, se notifican algunos tipos de espera relacionados con E/S (PAGEIOLATCH_UP, PAGEIOLATCH_EX). Supervise si estos tipos de espera siguen mostrando los valores más grandes wait_time , como se indica en la columna siguiente.

Captura de pantalla que muestra los tiempos de espera más grandes notificados en la columna siguiente.

Identificación de los tipos de espera de recuperación

Después de identificar un tipo de espera, use Modelo de repetición y rendimiento de la réplica secundaria del grupo de disponibilidad como referencia para los tipos de espera comunes que causan cola en la recuperación y para obtener instrucciones sobre cómo corregir el problema.

Subprocesos de recuperación bloqueados en réplicas secundarias de solo lectura

Si la solución dirige los informes (consultas) a las bases de datos del grupo de disponibilidad en una réplica secundaria, esas consultas de solo lectura adquieren bloqueos de estabilidad de esquema (Sch-S). Los bloqueos Sch-S pueden impedir que los subprocesos de rehacer adquieran bloqueos de modificación de esquema (Sch-M) —también conocidos como bloqueos Sch-M de modificación de esquema, o LCK_M_SCH_M— necesarios para aplicar cambios del lenguaje de definición de datos (DDL), como ALTER TABLE o ALTER INDEX. Un subproceso de rehacer bloqueado no puede aplicar registros de registro hasta que se desbloquee, lo que provoca la puesta en cola de recuperación.

Para comprobar si hay datos históricos de una operación de rehacer bloqueada, abra los archivos de seguimiento de eventos extendidos AlwaysOn_health en la réplica secundaria con SSMS. lock_redo_blocked Busque eventos.

Captura de pantalla que muestra la comprobación de la evidencia histórica de una fase de puesta al día bloqueada.

Use el Monitor de rendimiento para supervisar activamente el impacto del redo bloqueado en la cola de recuperación. Agregue los contadores SQL Server:Database Replica\Redo blocked/sec y SQL Server:Database Replica\Recovery Queue. La siguiente captura de pantalla muestra la ejecución de un comando ALTER TABLE ALTER COLUMN en la réplica principal mientras se ejecuta una consulta de larga duración en esa misma tabla de la réplica secundaria. El contador Rehacer bloqueado/s se dispara cuando se ejecuta el comando ALTER TABLE ALTER COLUMN. Mientras la consulta de larga duración esté activa en la misma tabla de la réplica secundaria, cualquier cambio posterior en la réplica principal aumenta la cola de recuperación.

Captura de pantalla que muestra un monitor para el tipo de espera de bloqueo de modificación del esquema.

Controle el tipo de espera de bloqueo de modificación de esquema que el subproceso de redo intenta adquirir. Use la consulta anterior para comprobar los tipos de espera notificados para las operaciones de redo en sys.dm_exec_requests. Puede ver cómo aumenta el tiempo de espera de LCK_M_SCH_M mientras el redo está bloqueado.

Captura de pantalla que muestra el tiempo de espera creciente para el LCK_M_SCH_M.

Recuperación de un solo hilo

SQL Server 2016 introdujo la recuperación en paralelo para las bases de datos de réplica secundaria. Si ejecuta una versión anterior, como SQL Server 2014 o SQL Server 2012, actualice a una versión compatible para obtener el rehacer paralelo y mejorar el rendimiento de la fase de puesta al día.

El rehacer de un solo hilo puede seguir produciéndose desde SQL Server 2016 hasta SQL Server 2019, que usan la arquitectura de recuperación en paralelo. En esas versiones, una instancia de SQL Server puede usar hasta 100 hilos para la repetición en paralelo. El sistema asigna subprocesos de puesta al día paralelos en las bases de datos del grupo de disponibilidad en función del número de procesadores y bases de datos, hasta ese total de 100 subprocesos. Cuando se alcanza el límite de 100 subprocesos, el sistema asigna algunas bases de datos en el grupo de disponibilidad un único subproceso de puesta al día.

Para comprobar si la base de datos de su grupo de disponibilidad usa la recuperación en paralelo, conéctese a la réplica secundaria y ejecute la siguiente consulta para contar las filas (subprocesos) que aplican la recuperación a la base de datos. En el ejemplo siguiente, si la agdb base de datos tiene una sola fila y su comando es DB STARTUP, la carga de trabajo de recuperación podría beneficiarse de la recuperación en paralelo.

SELECT db_name(database_id) AS dbname, command, session_id, database_id, wait_type, wait_time,
os.runnable_tasks_count, os.pending_disk_io_count FROM sys.dm_exec_requests der JOIN sys.dm_os_schedulers os
ON der.scheduler_id=os.scheduler_id
WHERE command IN ('PARALLEL REDO HELP TASK', 'PARALLEL REDO TASK', 'DB STARTUP')
AND database_id= db_id('agdb')

Captura de pantalla que muestra cómo determinar si la base de datos del grupo de disponibilidad usa la recuperación en paralelo.

Si la base de datos usa la fase de puesta al día de un solo subproceso, revise el algoritmo anterior para comprobar si SQL Server supera los 100 subprocesos de trabajo dedicados para la recuperación en paralelo. Alcanzar ese límite puede ser el motivo agdb por el que solo se usa un único subproceso de puesta al día.

SQL Server 2022 y versiones posteriores usan un algoritmo de recuperación en paralelo que asigna subprocesos de trabajo basados en la carga de trabajo, lo que elimina la posibilidad de que una base de datos ocupada permanezca en la fase de puesta al día de un solo subproceso. Para obtener más información, consulte la sección Uso de subprocesos por grupos de disponibilidad de "Requisitos previos, restricciones y recomendaciones para grupos de disponibilidad AlwaysOn".

Contenido relacionado

  • Last updated on