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?
Os Planos de Manutenção do SQL Server não têm funcionalidade incorporada para detectar o estado da réplica AG para um determinado banco de dados e agir de acordo. Para fazer isso, você deve implementar a funcionalidade personalizada.
Dependendo de como você está implementando suas tarefas de manutenção, existem algumas opções para isso.
Opção 1:
Se você estiver usando planos de manutenção do SQL, crie um conjunto de planos de manutenção por grupo de disponibilidade e direcione apenas os bancos de dados desse grupo. Remova os agendamentos desses planos e crie um trabalho do SQL Agent que seja executado no agendamento desejado. Faça com que o trabalho do Agente verifique sys.dm_hadr_availability_replica_states para confirmar que o AG em questão está no estado primário e, em caso afirmativo, execute os trabalhos do Agente apropriados para executar as tarefas do plano de manutenção.
Opção 2:
Se você estiver usando trabalhos do SQL Agent com scripts T-SQL para executar suas tarefas de manutenção, adicione alguma lógica aos scripts para verificar sys.dm_hadr_database_replica_states antes de executar para validar se o banco de dados em questão é realmente o principal.
Opção nº 3:
Redesenhe seus processos de manutenção para utilizar a excelente solução de manutenção da Ola Hallengren . Isso tem a lógica para lidar com Grupos de Disponibilidade já integrados, portanto, você economiza tempo ao projetar, testar e implantar uma solução por conta própria. Você simplesmente implanta um conjunto idêntico de trabalhos do Agente para executar os procedimentos armazenados em cada réplica. Todos eles serão executados, mas apenas aqueles que você deseja executar qualquer trabalho o farão.
Notas:
Qualquer uma dessas opções deve ser implantada de forma que os mesmos trabalhos sejam implantados em todas as réplicas e executados ao mesmo tempo. As únicas diferenças são que algumas tarefas são executadas apenas na réplica primária, enquanto outras apenas executam o trabalho e saem silenciosamente sem realizar nenhum trabalho devido ao estado da réplica.
Sua equipe de gerenciamento pode não gostar da ideia de refatorar os processos de manutenção atuais, mas a realidade é que eles precisam se quiserem automatizar isso para lidar com o failover, caso contrário, as tarefas de manutenção devem ser gerenciadas manualmente após o failover.
Acabei fazendo isso para o CheckDB. As outras tarefas simplesmente usarão o mesmo modelo. Funciona. Espero não estar perdendo nada importante.