Solucionar problemas de um banco de dados do Grupo de Disponibilidade no estado revertido

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

O que é reverter o estado?

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

As réplicas primária e secundária do grupo de disponibilidade permanecem em um estado conectado durante a operação normal para que as alterações na réplica primária sejam sincronizadas ativamente com as réplicas secundárias.

Durante failovers, esse estado conectado é cortado. Depois que a nova réplica primária estiver online, a conectividade será restabelecida entre a réplica primária e as réplicas secundárias. 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 esteja em sincronia com o primário.

Se uma transação grande estiver em execução no momento do failover, o novo log do banco de dados secundário estará à frente do banco de dados de réplica primária. O novo ponto de recuperação comum negociado exigirá que a réplica secundária receba páginas da réplica primária para que ela 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 acionam o estado de reversão dificilmente são notadas. A reversão do estado geralmente é observada quando o failover interrompe uma transação grande, fazendo com que muitas páginas sejam enviadas do primário para o secundário para reverter o banco de dados de réplica secundária para um estado recuperável.

Sintomas e efeito de um banco de dados do grupo de disponibilidade no estado revertido

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

Relatórios do painel Always On Não sincronizando no primário

Após o failover de um grupo de disponibilidade, você pode observar que o secundário é relatado como não sincronizando enquanto o failover foi bem-sucedido. O painel Always On relata Não sincronizando no primário e Revertendo no secundário.

Relatórios do painel Always On Não sincronizando no primário	Relatórios do painel Always On Revertendo no secundário

Relatórios de DMVs Always On NÃO SINCRONIZANDO no primário

Quando você consulta as seguintes DMVs (Exibições de Gerenciamento Dinâmico) de AGs (grupos de disponibilidade) Always On no primário, o banco de dados está no 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

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

As cargas de trabalho somente leitura e de relatório não conseguem acessar o banco de dados secundário

Enquanto o banco de dados secundário está sendo revertido, ele não pode ser acessado ou consultado. Essas cargas de trabalho somente leitura estão offline e são interrompidas. Dependendo de quanto tempo o banco de dados está no estado de reversão, pode ser necessário redirecionar essas cargas de trabalho para outra réplica secundária ou a réplica primária se essas cargas de trabalho forem comercialmente críticas.

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

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

Um aplicativo que tenta fazer logon no banco de dados de réplica secundária no estado revertido falha ao se conectar e gera o erro 18456:

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

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

Estime 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 do AlwaysOn_health XEvent

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

Conecte-se à réplica secundária usando o Pesquisador de Objetos do SSMS (SQL Server Management Studio) e analise Gerenciamento, Eventos Estendidos e, em seguida, 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 relatando o estado atual da operação de reversão. O estado é relatado a cada cinco minutos por meio do hadr_trace_message evento e a porcentagem concluída de operação de reversão é relatada.

Observação

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

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

Monitorar o tempo de conclusão da reversão usando o Monitor de Desempenho

Monitore o progresso do estado revertido usando os contadores de desempenho SQL Server:Réplica do Banco de Dados:Log Total Exigindo Desfazer e SQL Server:Réplica do Banco de Dados:Log Restante para Desfazer e escolha o banco de dados do grupo de disponibilidade para a Instância. No exemplo da captura de tela a seguir, o Log Total que Requer Desfazer é relatado como 56,3 mb e o Log Restante para Desfazer está caindo lentamente para 0 que está relatando o progresso da reversão.

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

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

Adicionar uma réplica secundária 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 a réplica primária enquanto a outra secundária conclui a reversão.

Importante

Não faça failover para uma réplica cujos bancos de dados estejam no 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 de réplica secundária que está no estado de reversão.

Como lidar com cargas de trabalho somente leitura com falha

Como os bancos de dados de réplica secundária na reversão estã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 a réplica primária ou para outra réplica secundária até que o banco de dados de réplica secundária 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 relata a hora de início da transação e a hora atual de todas as transações abertas 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