Aaron Rheams's questions

Eu tenho um ambiente com vários AGs em um único servidor e eles encontram uma situação de divisão em que alguns acabam em um nó e alguns acabam no outro nó (em um evento de failover, talvez). Quando as tarefas de manutenção (a gama básica de reindexação, atualização, etc.) são executadas nesses nós, elas apenas realizam operações efetivamente em bancos de dados que são read_write no lado primário de seus respectivos AGs. Isso faz com que o trabalho falhe, pois os bancos de dados são somente leitura nos secundários. Portanto, em uma situação de AG dividido, ambos os nós sempre mostrarão manutenção com falha no histórico de tarefas.

Escusado será dizer que é difícil monitorar esses clusters. Eu propus duas soluções possíveis para a gestão. Criamos scripts das tarefas de manutenção usando comandos DBCC para os bancos de dados individuais com base em suas propriedades de atualização ou simplesmente nos limitamos a um AG por servidor. Eles não gostam de nenhuma das duas soluções. Alguém sabe uma maneira de manter as tarefas internas de manutenção do SQL Server e direcioná-las apenas aos bancos de dados primários?

Sou DBA há cerca de 2 anos e há algumas sutilezas que ainda não entendo sobre os grupos de disponibilidade AlwaysOn. Em primeiro lugar, eles não foram nada além de problemas, tanto quanto posso dizer, principalmente por causa de uma situação que ocorre com frequência em nosso ambiente.

Fazemos patches do Windows uma vez por mês, com as reinicializações esperadas do servidor. Aproximadamente uma vez por mês, encontramos uma situação em que clusters com vários grupos de disponibilidade se dividem entre os nós de um cluster.

Se estou agendando trabalhos de backup, geralmente administro os trabalhos por meio da administração de vários servidores a partir de um servidor mestre. Faço isso na resolução do ouvinte, pois ele se conecta ao nó primário de um grupo de disponibilidade. O problema é que, se eu especificar "todos os bancos de dados", todo o nó tentará fazer backup, independentemente do status primário/secundário de um determinado grupo de disponibilidade.

Como resultado, muito ruído é gerado em nossas soluções de monitoramento, pois qualquer cluster com grupos de disponibilidade difusos retorna um status de falha para o backup, pois a falha ocorre na tentativa de fazer um backup normal (não somente cópia) em um AG secundário.

Preciso fazer scripts de trabalhos para serem executados por grupo de disponibilidade nesses casos?

Existe uma combinação de configurações que faz backup apenas de um grupo de disponibilidade primário para esse nó?

Eu defendi a consolidação dos grupos para que possamos administrar pelo SERVER em vez de pelo AG. Meus chefes argumentam que deveríamos usar AGs para balanceamento de carga entre clusters, de modo que não estejamos pagando uma licença SQL para um nó que usamos apenas para HADR. Eu apresentei tudo o que pode dar errado com esses AG's difusos, mas talvez haja algo que eu não esteja ciente.

Para maior clareza, entendo que podemos apontar ouvintes para os diferentes AGs e que eles se conectarão ao primário de seu respectivo nó. Eu simplesmente não consigo gerenciar qualquer tipo de plano de backup genérico que não produza conflitos de capacidade de monitoramento e gravação contra essas situações de AG dividido. Qualquer clareza que alguém possa oferecer seria muito apreciada.