Aumento expressivo do arquivo de log e dos arquivos da in-memory table após configuração do always on com diferentes versões

Bruno C94 0 Pontos de reputação
2024-10-10T20:30:30.2+00:00

Estou planejando um upgrade para a versão 2022 do SQL Server.
Eu fiz a seguinte configuração de always on:
SQL Primário -> Microsoft SQL Server 2017 (RTM-CU31) (KB5016884)
SQL Secundário -> Microsoft SQL Server 2017 (RTM-CU31) (KB5016884)
SQL Secundário com versão atualizada -> Microsoft SQL Server 2022 (RTM-CU15) (KB5041321)

Após realizar essa configuração, o dashboard do always on está 100% healthy, porém ao analisar a DMV sys.databases encontrei o seguinte: log_reuse_wait_desc = AVAILABILITY_REPLICA.

Isso indica uma falha de sincronização, porém analisando o dashboard, não encontrei nenhum delay expressivo.
Esse wait está resultando em um aumento do arquivo de log no servidor primário e também um acumulo de arquivos em disco da tabela in memory.
Após remover o SQL Server 2022 do AG em questão, o log é truncado com sucesso e os arquivos da tabela in memory também são limpos. - Estão sendo realizados bkps de log a cada 15min normalmente e as rotinas de bkp FULL e DIFF também.

Com isso eu cheguei a conclusão que esse problema é uma falha de sync entre a instancia primaria 2017 e a nova secundaria em 2022.

Porém não sei se isso é um comportamento normal. Alguém ja passou por esse cenário?

Minha suspeita é que isso acontece pois essa configuração de always on com versões diferentes/atualizadas do SQL mantém as bases como "Sycronized / In Recovery" até o momento do failover.
Talvez o estado In Recovery, esteja segurando as atualizações dos logs entre a instancia nova e a primaria.

Fiz algumas migrações dessa forma e nenhuma delas se comportou dessa maneira, a diferença dessa vez é que uma das databases nesse server utiliza in memory table(os logs e os arquivos de checkpoint estão aumentando somente para essa database, existem outras no AG e não notei aumento nos logs - mas elas não utilizam in memory tables)

sabem dizer se o estado in recovery na base secundaria pode segurar o truncate dos logs na primaria? Obrigado.

SQL Server
SQL Server
Uma família de sistemas de gerenciamento e análise de banco de dados relacional da Microsoft para soluções de comércio eletrônico, linha de negócios e data warehouse.
59 perguntas
0 comentários

2 respostas

Classificar por: Mais útil
Mais útil Mais Novo Mais Antigo
  1. Jonathan Pereira Castillo 8,180 Pontos de reputação Fornecedor da Microsoft
    2024-10-15T17:08:02.2966667+00:00

    Oi Bruno C94!

    Bem-vindo ao Microsoft Q&A!

    Parece que você está enfrentando um problema de sincronização entre as versões diferentes do SQL Server no seu grupo de disponibilidade Always On. Aqui estão algumas informações e sugestões que podem ajudar:

    1. Estado "In Recovery" e Truncamento de Logs:
      • O estado "In Recovery" na réplica secundária pode, de fato, impedir o truncamento dos logs na réplica primária. Isso ocorre porque a réplica secundária precisa estar totalmente sincronizada para que os logs possam ser truncados.
    2. Problemas de Sincronização com Versões Diferentes:
      • Utilizar versões diferentes do SQL Server em um grupo de disponibilidade Always On pode causar problemas de sincronização. A versão mais recente pode ter funcionalidades ou otimizações que não são totalmente compatíveis com a versão anterior.
    3. In-Memory Tables:
      • As tabelas in-memory podem aumentar a complexidade da sincronização, especialmente se a réplica secundária não estiver configurada para lidar adequadamente com essas tabelas. Isso pode resultar em um aumento dos arquivos de log e dos arquivos de checkpoint.
      Soluções Potenciais:
      • Verifique a Compatibilidade: Certifique-se de que todas as instâncias do SQL Server no grupo de disponibilidade estão configuradas para suportar as mesmas funcionalidades, especialmente no que diz respeito às tabelas in-memory.
      • Atualize as Réplicas: Considere atualizar todas as réplicas para a mesma versão do SQL Server para evitar incompatibilidades.
      • Monitoramento e Logs: Utilize ferramentas de monitoramento para verificar se há algum erro ou atraso específico que possa estar causando a falha de sincronização.

    Para mais detalhes sobre a configuração e solução de problemas do Always On, você pode consultar a documentação oficial da Microsoft

    Espero que essas dicas ajudem a resolver o problema! Se precisar de mais assistência, estou à disposição.

    Saudações

    Jonathan.

    -----------

    Sua opinião é muito importante para nós! Se esta resposta resolveu sua consulta, por favor clique em ‘YES‘. Isso nos ajuda a melhorar continuamente a qualidade e relevância de nossas soluções. Obrigado pela sua colaboração!

    0 comentários
  2. Jonathan Pereira Castillo 8,180 Pontos de reputação Fornecedor da Microsoft
    2024-11-05T16:48:04.86+00:00

    Oi Bruno C94!,

    O objetivo desta mensagem é verificar as informações fornecidas. Se tiver mais atualizações sobre este assunto, por favor, não hesite em responder neste mesmo tópico.

    Cuidadosamente                 

    Jonathan

    -----------

    Sua opinião é muito importante para nós! Se esta resposta resolveu sua consulta, por favor clique em ‘YES‘. Isso nos ajuda a melhorar continuamente a qualidade e relevância de nossas soluções. Obrigado pela sua colaboração!

    0 comentários

Sua resposta

As respostas podem ser marcadas como Respostas Aceitas pelo autor da pergunta, o que ajuda os usuários a saber a resposta que resolveu o problema do autor.