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 el estado de reversión?

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

Las réplicas principales y secundarias del grupo de disponibilidad permanecen en un estado conectado durante el funcionamiento 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 se reduce. 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 el nuevo secundario debe iniciar la recuperación para que esté sincronizado con el principal.

Si se ejecuta una transacción de gran tamaño en el momento de la conmutación por error, el nuevo registro de base de datos secundaria se adelanta a 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, ocurre a menudo y, normalmente, las transacciones pequeñas que desencadenan el estado de reversión apenas se notan. El estado de reversión suele observarse cuando la conmutación por error interrumpe una transacción de gran tamaño, lo que hace 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 lo 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 dar lugar a la pérdida de datos.

Always On informes de panel No sincronizando en la principal

Después de conmutar por error un grupo de disponibilidad, puede observar que la secundaria no se sincroniza mientras la conmutación por error se realizó correctamente. El panel de Always On informa de que no se sincroniza en la base de datos principal y se revierte en la secundaria.

Always On informes de panel No sincronizando en la principal	Always On informes del panel Revertir en la secundaria

Always On los informes de DMV NOT SYNCHRONIZING en el principal

Al consultar los siguientes Always On vistas de administración dinámica (DMV) de grupos de disponibilidad (AG) en la base de datos principal, la base de datos se encuentra en el 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 y de informes no pueden acceder a la base de datos secundaria

Mientras la base de datos secundaria se revierte, no se puede acceder a ella ni consultarla. Estas cargas de trabajo de solo lectura están sin conexión e interrumpidas. En función del tiempo que la base de datos esté en estado de reversión, puede ser necesario redirigir 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, Level 14, State 1, Line 2 Database 'agdb' is being recovered. Esperando hasta que finalice la recuperación.

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. Error en el inicio de sesión 2023-01-26 13:01:13.100 para el usuario "UserName>"<. Motivo: no se pudo abrir la base de datos explícitamente especificada "agdb". [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.

Estimación del 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 AlwaysOn_health XEvent

El AlwaysOn_health registro de diagnóstico de eventos extendido tiene un evento de hadr_trace_message que informa del 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, a continuación, las sesiones. Haga clic con el botón derecho en el evento AlwaysOn_health y seleccione Ver datos activos. Debería 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 en 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 SQL Server registro de errores en la réplica secundaria no es de gran ayuda al calcular la reversión de la finalización. En la siguiente imagen, puede observar de 10:08 a 11:03 , mientras que en estado de reversión, se notifica poco. Una vez que la secundaria ha recibido todas las páginas de la réplica principal, ahora puede revertir la transacción que se estaba ejecutando en la 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.

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

Supervise la reversión del progreso del estado mediante los contadores de rendimiento SQL Server:D atabase Replica:Total Log Requiring Undo y SQL Server:D atabase Replica:Log Remaining for Undo y elija la base de datos del grupo de disponibilidad para la instancia. En el ejemplo de la captura de pantalla siguiente, Total Log Requiring Undo se notifica como 56,3 mb y Log Remaining for Undo (Restante de registro para deshacer) baja lentamente a 0 , lo que indica que se está revirtiendo el progreso.

¿Cuáles son las otras opciones que no sean 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 se sincronice activamente con la réplica principal mientras que la otra secundaria finaliza la reversión.

Importante

No realice la conmutación 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 inutilizable 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 abordar cargas de trabajo de solo lectura con errores

Puesto que las bases de datos de réplica secundarias que se están revirtiendo no son accesibles, 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 la reversión del estado: supervisión de transacciones grandes

Si observa este estado con frecuencia durante las conmutaciones por error planeadas, implemente un procedimiento que compruebe si hay 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