SQL Server 2017 com 500 bancos de dados - AG freqüente desconecta desde CU9

Olá a todos e desde já agradecemos a sua ajuda. Estamos enfrentando desafios com os Grupos de Disponibilidade do SQL Server 2017.

fundo

A empresa é um software de back-end B2B de varejo. Cerca de 500 bancos de dados de inquilino único e 5 bancos de dados compartilhados usados ​​por todos os inquilinos. A característica da carga de trabalho é lida principalmente e a maioria dos bancos de dados possui atividade muito baixa.

Os servidores de produção física hospedados na co-localização foram atualizados recentemente do SQL Server 2014 Enterprise no Windows Server 2012 em uma configuração SAN / FCI compartilhada, para o SQL Server 2017 Enterprise no Windows Server 2016 em uma RAM de 2 soquetes / 32 núcleos / 768 GB Unidades SSD usando o AlwaysOn AG. O tráfego da AG usa portas 10G NIC dedicadas com uma conexão de cabo cruzado.

Seu requisito é que todos os bancos de dados façam failover juntos, então eles tiveram que colocá-los todos em um único AG. É uma réplica síncrona não legível em um servidor idêntico.

Os novos servidores estão em produção desde junho de 2018. As últimas atualizações de CU (CU7 na época) e do Windows foram instaladas e o sistema estava funcionando bem. Cerca de um mês depois, após atualizar os servidores de CU7 para CU9, eles começaram a perceber os seguintes desafios, listados em ordem de prioridade.

Temos monitorado os servidores usando o SQL Sentry e não observamos gargalos físicos. Todos os principais indicadores parecem bons. A CPU tem uma média de 20%, tempos de IO normalmente inferiores a 1ms, RAM não totalmente utilizada e rede <1%.

Desafios

Os sintomas parecem melhorar após o failover, mas voltam dentro de alguns dias, independentemente do servidor principal - os sintomas são idênticos nos dois servidores.

1. Tempo limite esporádico do cliente e falhas de conectividade, como

   ... ocorreu um erro ao estabelecer a conexão ...

   ou

   Tempo limite de execução expirado

   Às vezes, elas continuam por até 40 segundos e depois desaparecem.

2. A tarefa de backup do log de transações leva 10 vezes mais tempo para ser concluída do que antes. Anteriormente, demoravam de 2 a 3 minutos para fazer backup dos logs de todos os 500 bancos de dados, agora são necessários de 15 a 25. Verificamos que o próprio backup funciona bem com uma boa taxa de transferência. No entanto, há um pequeno atraso após a conclusão do backup de um log e antes de iniciar o próximo. começa muito baixo, mas dentro de um ou dois dias chega a 2-3 segundos. Multiplicado por 500 bancos de dados, e há a diferença.

3. Ocasionalmente, alguns bancos de dados aparentemente aleatórios ficam presos no estado "Não sincronizando" após o failover manual. A única maneira de resolver isso é reiniciar o serviço do SQL Server na réplica secundária ou remover e associar esses bancos de dados ao AG.

4. Outro problema introduzido pelo CU10 (e não resolvido no CU11): Conexões com o tempo limite secundário ao bloquear em master.sys.databases e até incapaz de usar o SSMS Object Explorer para réplica secundária. A causa raiz parece estar bloqueando pelo gravador VSS do Microsoft SQL Server, emitindo a seguinte consulta:

   select name, 
          recovery_model_desc, 
          state_desc, 
          CONVERT(integer, is_in_standby), 
          ISNULL(source_database_id,0) 
     from master.sys.databases
   

Observações

Acredito que encontrei a arma fumegante nos registros de erros. Os logs de erros estão cheios de mensagens AG, rotuladas como 'apenas informativas', mas parecem que elas não são normais e existe uma correlação muito forte de sua frequência com os erros do aplicativo.

Os erros são de vários tipos e vêm em seqüências:

• DbMgrPartnerCommitPolicy :: SetSyncState: GUID

• DbMgrPartnerCommitPolicy :: SetSyncAndRecoveryPoint: GUID

• A conexão dos Grupos de Disponibilidade AlwaysOn com o banco de dados secundário foi finalizada para o banco de dados primário 'XYZ' na réplica de disponibilidade 'DB' com o ID da Réplica: {GUID}. Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do usuário.

• Conexão dos Grupos de Disponibilidade AlwaysOn com o banco de dados secundário estabelecido para o banco de dados primário 'ABC' na réplica de disponibilidade 'DB' com o ID da Réplica: {GUID}. Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do usuário.

Alguns dias existem milhares de milhares.

Este artigo discute o mesmo tipo de sequência de erros no SQL 2016 e diz que é anormal. Isso também explica o fenômeno de 'não sincronização' após o failover. O assunto discutido foi para 2016 e foi corrigido no início deste ano em uma UC. no entanto, é a única referência relevante que eu poderia encontrar para os 2 primeiros tipos de mensagens, além de referências a mensagens de propagação inicial automáticas, que não devem ser o caso aqui, pois o AG já está estabelecido.

Aqui está um resumo dos erros diários na semana passada, para os dias com mais de 10 mil erros por tipo no PRIMARY (o secundário mostra 'perdendo a conexão com o primário ...'):

Date        Message Type (First 50 characters)                  Num Errors
10/8/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  61953
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  56812
10/4/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  27951
10/2/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  24158
10/7/2018   DbMgrPartnerCommitPolicy::SetSyncAndRecoveryPoint:  14904
10/8/2018   Always On Availability Groups connection with seco  13301
10/3/2018   DbMgrPartnerCommitPolicy::SetSyncState: 783CAF81-4  11057
10/3/2018   Always On Availability Groups connection with seco  10080

Ocasionalmente, também vemos mensagens "estranhas", como:

O banco de dados do grupo de disponibilidade "DB" está alterando as funções de "SECONDARY" para "SECONDARY" porque a sessão de espelhamento ou o grupo de disponibilidade falhou devido à sincronização de funções. Esta é apenas uma mensagem informativa. Não é necessária nenhuma ação do usuário.

... entre uma série de estados em mudança de "SECUNDARY" para "RESOLVING".

Após o failover manual, o sistema pode ficar vários dias sem uma única mensagem desses tipos e, de repente, sem motivo aparente, receberemos milhares de uma só vez, o que, por sua vez, faz com que o servidor não responda e cause aplicativos tempos limite de conexão. Este é um erro crítico, pois alguns de seus aplicativos não incorporam um mecanismo de nova tentativa e, portanto, podem perder dados. Quando ocorre uma explosão de erros, os seguintes tipos de espera são disparados. Isso mostra as esperas logo após o AG parecer ter perdido a conexão com todos os bancos de dados de uma só vez:

Cerca de 30 segundos depois, tudo volta ao normal em termos de espera, mas as mensagens do AG continuam inundando os logs de erros em taxas variadas e em diferentes horários do dia, horários aparentemente aleatórios, incluindo horários de pico. O aumento simultâneo da carga de trabalho durante essas explosões de erros piora as coisas, é claro. Se apenas alguns bancos de dados forem desconectados, isso normalmente não causa o tempo limite das conexões, pois é resolvido com rapidez suficiente.

Tentamos verificar se foi realmente o CU9 que iniciou o problema, mas conseguimos fazer o downgrade de ambos os nós apenas para o CU9. Tentativas de fazer o downgrade de um nó para CU8, resultaram em um nó preso no estado 'Resolvendo', mostrando o mesmo erro no log:

Não é possível ler a configuração persistente do grupo de disponibilidade Always On com o ID do recurso correspondente '…. A configuração persistente é gravada por um SQL Server de versão superior que hospeda a réplica de disponibilidade principal. Atualize a instância local do SQL Server para permitir que a réplica de disponibilidade local se torne uma réplica secundária.

Isso significa que teremos que apresentar um tempo de inatividade para poder fazer o downgrade de ambos os nós para CU8 ao mesmo tempo. Isso também sugere que houve uma grande atualização na AG que pode explicar o que estamos enfrentando.

Já tentamos ajustar o max_worker_threads do padrão 0 (= 960 em nossa caixa com base neste artigo ) gradualmente para 2.000, sem impacto observado nos erros.

O que podemos fazer para resolver essas desconexões AG? Alguém aí está enfrentando problemas semelhantes? Outras pessoas com grande número de bancos de dados em um AG podem ver mensagens semelhantes no log de erros do SQL começando com CU9 ou CU8?

Agradecemos antecipadamente por qualquer ajuda!

Atualizar:

1. As desconexões do Grupo de disponibilidade frequente foram confirmadas como uma regressão introduzida pelo CU9 e foram resolvidas após a instalação do CU12.

2. Os problemas de bloqueio na réplica secundária foram confirmados como um problema com uma atualização do código do gravador VSS que foi introduzido no CU10. Esperamos que seja resolvido na CU 13. A solução provisória é substituir manualmente as DLLs do gravador VSS pelas DLLs anteriores à CU10 ...

   BEGIN RANT-SACTION;

   Infelizmente, a Microsoft parece falhar repetidamente no controle de qualidade adequado, não apenas nas atualizações do Windows 10, mas também em softwares de missão crítica empresarial, como o SQL Server.

   Eu preferia muito sua estratégia anterior de service packs, pelo menos eles tinham tempo suficiente para testá-los adequadamente antes de infligir crise de produção e perda de dados a seus clientes com o lançamento descuidado de atualizações incompletas.

   COMMIT RANT-SACTION;

Você verificou os threads de trabalho? Normalmente, sempre use mais thread de trabalhadores para trabalhar e, normalmente, o valor padrão não é suficiente. Eu tive o mesmo problema com 600 bancos de dados em um sempre ativado. Portanto, adicionamos mais threads ao paramater de instância e isso corrigiu nosso problema. Espero que isto ajude!