Impossibile troncare il registro delle transazioni, log_reuse_wait_desc - DISPONIBILITÀ_REPLICA

Questa mattina sono stato svegliato da un avviso completo del registro delle transazioni su uno dei nostri database. Questo server è un cluster alwayson e anche un abbonato di replica transazionale. Ho controllato log_reuse_wait_desc e ha mostrato logbackup. Qualcuno aveva disabilitato accidentalmente i processi di backup 4 giorni prima, ho riabilitato il processo di backup del registro e il registro è stato cancellato. Dato che erano le 4 del mattino, ho pensato di andare in ufficio più tardi quella mattina e di sottrarmi al registro in quanto è cresciuto fino a 400 GB.

10 AM - Sono in ufficio e controllo l'utilizzo del registro prima di ridurlo ed era del 16% circa. Sono stato sorpreso e ho controllato il log_reuse_wait_desc, che mostrava la replica. Ero confuso perché questo era un abbonato di replica. Abbiamo quindi visto che il db era abilitato per CDC e abbiamo pensato che potesse essere la causa, quindi disabilitato CDC e ora log_reuse_wait_desc mostra DISPONIBILITÀ_REPLICA.

L'utilizzo dei log nel frattempo è ancora in costante crescita ed è al 17% ora. Controllo la dashboard di Alwayson e controllo la coda di invio e ripetizione ed entrambi sono praticamente zero. Non sono sicuro del motivo per cui il riutilizzo del registro viene visualizzato come DISPONIBILITÀ_REPLICA e non riesco a cancellare il registro.

Qualche idea sul perché questo stia accadendo?

Se lo fai:

SELECT * FROM sys.databases

E log_reuse_wait_desc mostra AVAILABILITY_REPLICA, ciò significa che SQL Server è in attesa di inviare i dati di registro a una delle repliche del gruppo Always On Availability. Una delle repliche potrebbe essere in ritardo a causa di una rete lenta o potrebbe essere completamente inattiva.

Se controlli la dashboard di AG e non mostra code, potresti essere stato vittima dell'esaurimento del thread. È un problema noto che il dashboard di AG interrompe l'aggiornamento dopo l'esaurimento del thread di lavoro. Dovrai controllare direttamente lo stato di ogni replica anziché fare affidamento sul primario. La nota di Nick in quell'elemento Connect dice che puoi semplicemente modificare le proprietà di una replica per riavviare la replica, ma ciò non sempre funziona (specialmente se hai una centinaia di database su una replica con una grande quantità di dati che devono essere inviati, e il riavvio della replica può causare nuovamente l'esaurimento del thread di lavoro.)

Se l'ultimo ragazzo ha impostato una replica AG e non dovrebbe più esistere, allora è il momento di rimuovere quella AG e / o replica. Fai solo attenzione che le app non puntino al nome del listener per connettersi a SQL Server.