Eu apreciaria alguns conselhos, por favor.
Configurei a propagação automática para meu SQL 2019 Availability Group. Meus dois nós de cluster têm, cada um, 8 GB de RAM e 4 processadores. Os bancos de dados menores na instância são adicionados com êxito ao AG sem problemas. No entanto, um banco de dados de 30 GB continua exibindo um aviso sobre espaço livre em disco insuficiente para dados e arquivos de log quando tento adicioná-lo ao AG. O armazenamento de arquivos de dados tem cerca de 70 GB livres e o armazenamento de logs cerca de 74 GB livres.
Eu ignoro a mensagem e continuo adicionando o banco de dados ao AG e obtive comportamentos diferentes da seguinte forma:
Às vezes, parece ter sido adicionado com sucesso ao AG, pois o painel do SSMS mostra o AG como íntegro. No entanto, o DMV sys.dm_server_hadr_automatic_seeding mostra o status de propagação em um nó às vezes como CONCLUÍDO (failure_state_desc = NULL) enquanto o outro nó FAILED (failure_state_desc = Verifique se a propagação é necessária). Às vezes, ambos os nós como FAILED.
Algumas vezes eu tive um errorlog de despejo SQL
Em uma ocasião, parecia bem-sucedido, mas não consegui atualizar a conexão do nó secundário no SSMS e recebi um errorlog de despejo SQL
Em todas as ocasiões, descobri que a utilização de memória no Gerenciador de tarefas atinge mais de 4 GB. Minha memória máxima configurada do SQL Server é de cerca de 5 GB.
Observe que o sistema legado para esta nova implantação não usa tecnologia AG e usa tamanhos muito menores de espaço em disco para dados e arquivos de log e é executado com êxito em sua versão mais antiga do SQL.
Minhas perguntas por favor:
- A propagação automática é conhecida por consumir muita memória e/ou espaço em disco?
- Em caso afirmativo, existe alguma maneira de contornar esse problema se eu ainda quiser usar a propagação automática?
- devo procurar a especificação dos nós ou apenas melhor usar a propagação manual?
Eu fiz algumas pesquisas sobre o assunto, mas apreciaria alguns conselhos, se alguém puder fornecer alguns.
obrigado
Depende da sua definição de "muito". A propagação automática faz um backup de VDI no primário e transmite a restauração para (cada) secundário de propagação. Os backups usam agendadores ocultos e memória fora do buffer pool. Portanto, pedantemente, a semeadura automática em si não, mas partes dos processos subjacentes o fazem.
Se você tiver um servidor minúsculo (que eu pessoalmente consideraria 8 GB e 4 cpus um servidor muito pequeno), isso exigirá uma porcentagem maior de recursos gerais do que em um servidor maior (por exemplo, 24 núcleos e 128 GB de memória).
Além disso, a propagação automática pode executar 5 sessões simultaneamente, o que significa que se você tiver 5 ou mais bancos de dados que precisam ser propagados, todos eles executarão backups e restaurações, o que significa que seu sistema precisa ser capaz de lidar com tantos itens simultâneos.
Não, realmente não. Aposto que se você der ao servidor mais espaço em disco + CPU + memória, ele semeará bem.
Não acredito que possamos responder a essa pergunta. Não sabemos por que eles são dimensionados como são ou quais escolhas ou decisões subjacentes podem envolver isso. Por exemplo, existem custos de licenciamento, restrições de infraestrutura, carga de trabalho simultânea insuficiente para justificar, etc.