No se puede truncar el registro de transacciones, log_reuse_wait_desc - AVAILABILITY_REPLICA

Esta mañana me despertó una alerta completa del registro de transacciones en una de nuestras bases de datos. Este servidor es siempre un clúster y también un suscriptor de replicación transaccional. Revisé log_reuse_wait_desc y mostró logbackup. Alguien había deshabilitado accidentalmente los trabajos de respaldo 4 días antes, volví a habilitar el trabajo de respaldo de registro y el registro se borró. Como eran las 4 de la mañana, pensé que iría a la oficina más tarde esa mañana y evitaría el registro, ya que ha crecido a 400 GB.

10 AM- Estoy en la oficina y verifico el uso del registro antes de reducir y era alrededor del 16%. Me sorprendió y revisé el log_reuse_wait_desc, que mostró replicación. Estaba confundido porque este era un suscriptor de replicación. Luego vimos que la base de datos estaba habilitada para CDC y pensamos que esa podría ser la causa, por lo que deshabilitó CDC y ahora log_reuse_wait_desc muestra AVAILABILITY_REPLICA.

Mientras tanto, el uso de registros sigue creciendo constantemente y ahora es del 17%. Verifico el tablero de mandos de alwayson y compruebo la cola enviada y rehacer y ambos son prácticamente cero. No estoy seguro de por qué la reutilización del registro se muestra como AVAILABILITY_REPLICA y no se puede borrar el registro.

¿Alguna idea de por qué está sucediendo esto?

Si haces esto:

SELECT * FROM sys.databases

Y log_reuse_wait_desc muestra AVAILABILITY_REPLICA, lo que significa que SQL Server está esperando enviar datos de registro a una de sus réplicas del grupo de disponibilidad Always On. Una de las réplicas puede estar rezagada debido a una red lenta, o puede estar inactiva por completo.

Si revisa el panel de control de AG y no muestra colas, es posible que haya sido víctima del agotamiento del hilo. Es un problema conocido que el panel de control AG deja de actualizarse después del agotamiento del hilo de trabajo. Deberá verificar el estado de cada réplica directamente en lugar de confiar en el primario. La nota de Nick en ese elemento Connect dice que solo puede alterar las propiedades de una réplica para reiniciar la replicación, pero eso no siempre funciona (especialmente si tiene cientos de bases de datos en una réplica con una gran cantidad de datos que deben enviarse, y reiniciar la replicación solo puede provocar el agotamiento del subproceso de trabajo nuevamente).

Si el último tipo configuró una réplica AG y se supone que ya no existe, entonces es hora de eliminar esa AG y / o réplica. Solo tenga cuidado de que las aplicaciones no apunten al nombre del oyente para conectarse a su SQL Server.