Solución de problemas de una base de datos de grupo de disponibilidad en estado de reversión

Este artículo le ayuda a solucionar problemas de una base de datos de grupo de disponibilidad en estado de reversión.

¿Qué es la reversión del estado?

El estado de reversión se produce cuando el servidor secundario debe deshacer los cambios que ya se han aplicado para volver a sincronizarse con el servidor principal.

Las réplicas principales y secundarias del grupo de disponibilidad permanecen en un estado conectado durante la operación normal para que los cambios en la réplica principal se sincronicen activamente con las réplicas secundarias.

Durante las conmutaciones por error, este estado conectado está grave. Una vez que la nueva réplica principal se ha conectado, se restablece la conectividad entre la réplica principal y las réplicas secundarias. Durante este estado conectado inicial, se negocia un punto de recuperación común en el que la nueva base de datos secundaria debe iniciar la recuperación para que esté sincronizada con la principal.

Si se ejecuta una transacción grande en el momento de la conmutación por error, el nuevo registro de base de datos secundario está por delante de la base de datos de réplica principal. El nuevo punto de recuperación común negociado requerirá que la réplica secundaria reciba páginas de la réplica principal para que esté en un estado en el que se pueda reanudar la sincronización. El proceso de reversión también se denomina "Deshacer de rehacer".

El proceso de reversión es inherentemente lento, se produce a menudo y normalmente pequeñas transacciones que desencadenan el estado de reversión apenas se notan. A menudo se observa el estado de reversión cuando la conmutación por error interrumpe una transacción grande, lo que provoca que muchas páginas se envíen desde la base de datos principal a la secundaria para revertir la base de datos de réplica secundaria a un estado recuperable.

Síntomas y efecto de una base de datos de grupo de disponibilidad en estado de reversión

Cuando una base de datos está en estado de reversión en la réplica secundaria, la base de datos no se sincroniza y, por tanto, no recibe cambios de la réplica principal. Una pérdida repentina de la base de datos en la réplica principal podría provocar la pérdida de datos.

Informes del panel AlwaysOn Sin sincronizar en la principal

Después de conmutar por error un grupo de disponibilidad, puede observar que la base de datos secundaria se notifica como no sincronizada mientras la conmutación por error se realizó correctamente. El panel AlwaysOn informa de no sincronizar en la base de datos principal y revertir a la secundaria.

Informes del panel AlwaysOn Sin sincronizar en la principal	Informes del panel AlwaysOn Reversión en la base de datos secundaria

Los DMV AlwaysOn notifican NOT SYNCHRONIZING en la principal

Al consultar las siguientes vistas de administración dinámica (DMV) de los grupos de disponibilidad AlwaysOn (AG) en la base de datos principal, la base de datos se encuentra en estado NOT SYNCHRONIZING .

SELECT DISTINCT ar.replica_server_name, drcs.database_name, drs.database_id, drs.synchronization_state_desc, drs.database_state_desc
FROM sys.availability_replicas ar 
JOIN sys.dm_hadr_database_replica_states drs 
ON ar.replica_id=drs.replica_id 
JOIN sys.dm_hadr_database_replica_cluster_states drcs
ON drs.group_database_id=drcs.group_database_id

Al consultar las DMV en la base de datos secundaria, la base de datos del grupo de disponibilidad está en estado REVERTING .

Las cargas de trabajo de solo lectura e informes no pueden acceder a la base de datos secundaria

Mientras se revierte la base de datos secundaria, no se puede acceder a ella ni consultarla. Estas cargas de trabajo de solo lectura están sin conexión y se interrumpen. En función del tiempo que la base de datos esté en estado de reversión, puede ser necesario volver a enrutar esas cargas de trabajo a otra réplica secundaria o a la réplica principal si estas cargas de trabajo son críticas para la empresa.

Si tiene una carga de trabajo de solo lectura, como una carga de trabajo de informes que se enruta a la réplica secundaria, estos lotes pueden producir un error con el mensaje 922:

Msg 922, Nivel 14, Estado 1, Línea 2 Base de datos "agdb" se está recuperando. Esperando a que la recuperación termine.

Una aplicación que intenta iniciar sesión en la base de datos de réplica secundaria en estado de reversión no se puede conectar y genera el error 18456:

2023-01-26 13:01:13.100 Error de inicio de sesión: 18456, Gravedad: 14, Estado: 38. 2023-01-26 13:01:13.100 Error de inicio de sesión del usuario "<UserName>". Motivo: No se pudo abrir la base de datos "agdb" especificada explícitamente. [CLIENTE: <equipo> local]

Este error también se puede notificar en el registro de errores de SQL Server si se auditan los inicios de sesión con errores.

Calcular el tiempo restante en estado de reversión

Use uno de los métodos siguientes para calcular el tiempo restante en estado de reversión:

Uso de la sesión de XEvent de AlwaysOn_health

El AlwaysOn_health registro de diagnóstico de eventos extendidos tiene un evento de hadr_trace_message que notifica el progreso del estado de reversión cada cinco minutos.

Conéctese a la réplica secundaria mediante SQL Server Management Studio (SSMS) Explorador de objetos y explore en profundidad la administración, los eventos extendidos y las sesiones. Haga clic con el botón derecho en el evento AlwaysOn_health y seleccione Ver datos en directo. Debe obtener una nueva ventana con pestañas que informe del estado actual de la operación de reversión. El estado se notifica cada cinco minutos a través del hadr_trace_message evento y se notifica el porcentaje completado de la operación de reversión.

Nota:

El evento hadr_trace_message extendido se agregó a las actualizaciones acumulativas más recientes de SQL Server 2019 y versiones posteriores. Debe ejecutar las actualizaciones acumulativas más recientes para observar este evento extendido en la AlwaysOn_health sesión de eventos extendidos.

El registro de errores de SQL Server en la réplica secundaria no es mucho útil al calcular la reversión de la finalización. En la siguiente imagen, puede observar de 10:08 a 11:03 mientras se revierte el estado, se notifica poco. Una vez que la base de datos secundaria ha recibido todas las páginas de la réplica principal, ahora puede revertir la transacción que se estaba ejecutando en el principal original que desencadenó el estado de reversión. La recuperación se ejecuta de 11:03 a 11:05. Poco después de que se complete la recuperación, la base de datos debe empezar a sincronizarse con la réplica principal y ponerse al día de todos los cambios realizados en la base de datos principal mientras la base de datos secundaria estaba en estado de reversión.

Supervisar la reversión del tiempo de finalización mediante Monitor de rendimiento

Supervise el progreso del estado de reversión mediante los contadores de rendimiento SQL Server:Réplica de base de datos:Registro total que requieren deshacer y SQL Server:Réplica de base de datos:Registro restante para deshacer y elija la base de datos del grupo de disponibilidad para la instancia. En el ejemplo de la captura de pantalla siguiente, el registro total que requiere deshacer se notifica como 56,3 mb y el registro restante para deshacer se reduce lentamente a 0 que notifica la reversión del progreso.

¿Cuáles son sus otras opciones que no son esperar?

Microsoft recomienda calcular el tiempo de finalización del estado de reversión.

Adición de una réplica secundaria a un grupo de disponibilidad

Si solo hay dos réplicas en el grupo de disponibilidad, si es posible, agregue otra réplica secundaria que pueda proporcionar alta disponibilidad y redundancia y sincronizarse activamente con la réplica principal, mientras que la otra secundaria finaliza la reversión.

Importante

No conmute por error a una réplica cuyas bases de datos están en estado de reversión. Esto puede dar lugar a una base de datos no utilizable que requiera una restauración a partir de la copia de seguridad. No reinicie la instancia de réplica secundaria, no acelerará este proceso y puede poner en peligro el estado de la base de datos de réplica secundaria que está en estado de reversión.

Cómo solucionar errores en las cargas de trabajo de solo lectura

Dado que las bases de datos de réplica secundaria en la reversión son inaccesibles, se producen errores en las cargas de trabajo de solo lectura. Actualice la tabla de enrutamiento de intención de lectura para enrutar el tráfico a la réplica principal o a otra réplica secundaria hasta que la base de datos de réplica secundaria afectada complete el proceso de reversión.

Evitar revertir el estado: supervisión de transacciones grandes

Si observa este estado con frecuencia durante conmutación por error planeada, implemente un procedimiento que compruebe las transacciones grandes antes de las conmutaciones por error. La consulta siguiente notifica la hora de inicio de la transacción y la hora actual de las transacciones abiertas en el sistema y proporciona el búfer de entrada de las transacciones.

SELECT tat.transaction_begin_time, getdate() AS 'current time', es.program_name, es.login_time, es.session_id, tst.open_transaction_count, eib.event_info
FROM sys.dm_tran_active_transactions tat
JOIN sys.dm_tran_session_transactions tst ON tat.transaction_id=tst.transaction_id
JOIN sys.dm_exec_sessions es ON tst.session_id=es.session_id 
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) eib WHERE es.is_user_process = 1
ORDER BY tat.transaction_begin_time ASC