Solucionar problemas de um banco de dados do Grupo de Disponibilidade no estado de reversão

Este artigo ajuda você a solucionar problemas de um banco de dados de grupo de disponibilidade no estado de reversão.

O que está revertendo o estado?

O estado de reversão ocorre quando o servidor secundário deve desfazer as alterações que ele já aplicou para voltar a sincronizar com o primário.

As réplica primárias e secundárias do grupo de disponibilidade permanecem em um estado conectado durante a operação normal para que as alterações no réplica primário sejam sincronizadas ativamente com os réplica(s) secundários.

Durante failovers, esse estado conectado é cortado. Depois que o novo réplica primário estiver online, a conectividade será restabelecida entre o réplica primário e os réplica(s) secundários. Durante esse estado conectado inicial, um ponto de recuperação comum é negociado no qual o novo secundário deve iniciar a recuperação para que ele esteja em sincronia com o primário.

Se uma transação grande estiver sendo executada no momento do failover, o novo log de banco de dados secundário estará à frente do banco de dados réplica primário. O novo ponto de recuperação comum negociado exigirá que o réplica secundário receba páginas do réplica primário para que ele esteja em um estado em que a sincronização possa ser retomada. O processo de reversão também é chamado de "Desfazer de Refazer".

O processo de reversão é inerentemente lento, acontece com frequência e, normalmente, pequenas transações que disparam o estado revertido dificilmente são notadas. O estado de reversão geralmente é notado quando o failover interrompe uma grande transação, fazendo com que muitas páginas sejam enviadas do primário para o secundário para reverter o banco de dados secundário réplica para um estado recuperável.

Sintomas e efeito de um banco de dados de grupo de disponibilidade no estado de reversão

Quando um banco de dados está em estado de reversão no réplica secundário, o banco de dados não é sincronizado e, portanto, não recebe alterações do réplica primário. Uma perda repentina do banco de dados no réplica primário pode resultar em perda de dados.

Always On dashboard relata não sincronizar no primário

Depois de falhar em um grupo de disponibilidade, você pode observar que o secundário é relatado como não sincronizando enquanto o failover foi bem-sucedido. O Always On dashboard relata Não Sincronizar no primário e Reverter no secundário.

Always On dashboard relata não sincronizar no primário	Always On dashboard relatórios revertendo no secundário

Always On DMVs relata NÃO SINCRONIZAR no primário

Ao consultar os seguintes DMVs (grupos de disponibilidade) Always On (AGs) no primário, o banco de dados está no estado NÃO SINCRONIZANDO.

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

Quando você consulta os DMVs no secundário, o banco de dados do grupo de disponibilidade está no estado REVERTING .

Cargas de trabalho somente leitura e relatórios não acessam o banco de dados secundário

Enquanto o banco de dados secundário está revertendo, ele não pode ser acessado ou consultado. Essas cargas de trabalho somente leitura estão offline e interrompidas. Dependendo de quanto tempo o banco de dados está em estado de reversão, talvez seja necessário redirecionar essas cargas de trabalho para outro réplica secundário ou o réplica primário se essas cargas de trabalho forem críticas aos negócios.

Se você tiver uma carga de trabalho somente leitura, como uma carga de trabalho de relatório roteada para o réplica secundário, esses lotes poderão falhar com a mensagem 922:

Msg 922, Nível 14, Estado 1, Banco de Dados da Linha 2 'agdb' está sendo recuperado. Aguardando até que a recuperação seja concluída.

Um aplicativo que tenta fazer logon no banco de dados secundário réplica no estado de reversão não consegue se conectar e gera o erro 18456:

2023-01-26 13:01:13.100 Erro de logon: 18456, Gravidade: 14, Estado: 38. Falha no logon de logon 2023-01-26 13:01:13.100 Logon para o usuário '<UserName>'. Motivo: falha ao abrir o banco de dados explicitamente especificado 'agdb'. [CLIENTE: <computador> local]

Esse erro também pode ser relatado no log de erros SQL Server se os logons com falha estiverem sendo auditados.

Estimar o tempo restante no estado de reversão

Use um dos seguintes métodos para estimar o tempo restante no estado de reversão:

Usar a sessão XEvent AlwaysOn_health

O AlwaysOn_health log de diagnóstico de eventos estendidos tem um evento hadr_trace_message que relata a reversão do progresso do estado a cada cinco minutos.

Conecte-se ao réplica secundário usando Pesquisador de Objetos de SQL Server Management Studio (SSMS) e faça drill em Gerenciamento, Eventos Estendidos e sessões. Clique com o botão direito do mouse no evento AlwaysOn_health e selecione Assistir Dados ao Vivo. Você deve obter uma nova janela com guias informando o estado atual da operação de reversão. O estado é relatado a cada cinco minutos por meio do hadr_trace_message evento e o percentual concluído de operação de reversão é relatado.

Observação

O evento hadr_trace_message estendido foi adicionado às atualizações cumulativas mais recentes no SQL Server 2019 e posteriores. Você deve estar executando as atualizações cumulativas mais recentes para observar esse evento estendido na AlwaysOn_health sessão de eventos estendidos.

O log de erros SQL Server no réplica secundário não ajuda muito ao estimar a conclusão revertida. Na imagem a seguir, você pode observar de 10:08 a 11:03 enquanto estiver em estado de reversão, pouco é relatado. Depois que o secundário receber todas as páginas do réplica primário, agora ele poderá reverter a transação que estava em execução na primária original que desencadeou o estado de reversão. A recuperação é executada das 11h03 às 11h05. Logo após a conclusão da recuperação, o banco de dados deve começar a sincronizar com o réplica primário e acompanhar todas as alterações feitas no primário enquanto o banco de dados secundário estava em estado de reversão.

Monitorar o tempo de conclusão revertido usando Monitor de Desempenho

Monitore a reversão do progresso do estado usando os contadores de desempenho SQL Server:D atabase Replica:Log Total Exigindo Desfazer e SQL Server:D atabase Replica:Log Restante para Desfazer e escolha o banco de dados do grupo de disponibilidade para a Instância. No exemplo na captura de tela a seguir, Total log que exige desfazer é relatado como 56,3 mb, e Log Restante para Desfazer está caindo lentamente para0 que está relatando o progresso revertido.

Quais são suas outras opções além de esperar?

A Microsoft recomenda que você estima o tempo para conclusão do estado de reversão.

Adicionar um réplica secundário a um grupo de disponibilidade

Se houver apenas duas réplicas no grupo de disponibilidade, se possível, adicione outra réplica secundária que possa fornecer alta disponibilidade e redundância e sincronizar ativamente com o réplica primário enquanto o outro secundário concluir a reversão.

Importante

Não falhe em um réplica cujos bancos de dados estão em estado de reversão. Isso pode resultar em um banco de dados inutilizável que requer uma restauração do backup. Não reinicie a instância de réplica secundária, ela não acelerará esse processo e poderá comprometer o estado do banco de dados secundário réplica que está em estado de reversão.

Como lidar com cargas de trabalho somente leitura com falha

Como os bancos de dados secundários réplica em reverter são inacessíveis, as cargas de trabalho somente leitura estão falhando. Atualize a tabela de roteamento de intenção de leitura para rotear o tráfego de volta para o réplica primário ou para outro réplica secundário até que o banco de dados secundário réplica afetado conclua o processo de reversão.

Evitar reverter o estado – monitorar transações grandes

Se você estiver observando esse estado com frequência durante failovers planejados, implemente um procedimento que verifique se há transações grandes antes dos failovers. A consulta a seguir informa que a transação inicia a hora e a hora atual de qualquer transação aberta no sistema e fornece o buffer de entrada das transações.

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