Em uma configuração do MS SQL Server 2014 AlwaysOn AG, gostaria de agendar trabalhos de backup para um determinado grupo de disponibilidade. O objetivo final é fazer com que os backups regulares sejam executados no secundário sincronizado e, mais importante, não vinculados à disponibilidade de um nó secundário específico.
A abordagem que vi até agora foi usar o agendador do SQL Server, configurar tarefas idênticas em todas as instâncias em execução e introduzir lógica condicional nas etapas do agendador para determinar se a função é primária ou secundária. Isso não funcionará para o meu caso de uso por vários motivos:
- Desejo executar a ação agendada em um secundário apenas uma vez, mas tenho vários secundários
- Eu quero garantir que ele seja executado, independentemente de haver algum secundário restante - se nenhum secundário for deixado, ele deve ser executado no primário
A tarefa de backup consiste em executar a BACKUP LOG [...] WITH COMPRESSION, NOINIT, NOFORMATcada 15 minutos.
No momento, estou pensando em criar uma tarefa agendada em cluster vinculada à função de cluster de failover do respectivo AG, mas gostaria de saber se há uma maneira mais fácil e simplificada de implementar isso.
Isso pode ser feito sem problemas. Apenas tenha em mente que seus sistemas devem ser especificados para serem capazes de suportar a carga total da mecânica de sincronização para Grupos de Disponibilidade AlwaysOn, além do refazer necessário, além dos backups. A última coisa que você deseja é sobrecarregar seu sistema IO e causar interrupções ou uma grande fila de refazer. Isso pressupõe que não esteja sendo usado ativamente como um secundário legível - se estiver, você deve levar isso em consideração e observar os encadeamentos de redo bloqueados.
Há uma configuração de Grupo de Disponibilidade e uma função do sistema que pode ser usada para realizar isso dentro das diretrizes esperadas.
A primeira é a configuração, por AG, chamada
AUTOMATED_BACKUP_PREFERENCEque possui quatro opções diferentes . O que você está descrevendo é chamadoSECONDARY, que preferirá qualquer nó secundário ao nó primário. O nó secundário escolhido é peloBACKUP_PRIORITYque é definido por réplica variando de 0 a 100, onde quanto maior o número mais peso ele tem. Se houver um empate em pesos para réplicas secundárias, a réplica que for classificada primeiro dada a ordenação do sistema será escolhida. Se todas as réplicas secundárias falharem, a réplica primária será escolhida.A segunda parte da equação é a função do sistema usada para verificar se a réplica que está executando o trabalho é a réplica preferencial com base nos valores do parágrafo anterior. Essa função do sistema é chamada sys.fn_hadr_backup_is_preferred_replica(). Dado um nome de banco de dados (qualquer banco de dados no AG), um valor de 0 será retornado se não for a réplica preferida e um valor de 1 se for a preferida.
Ao criar o trabalho do agente para realizar isso, convém agrupar a lógica de backup em uma
IFcondicional para verificar a réplica preferencial. É isso. Coloque o trabalho de agente idêntico em todas as réplicas.Certifique-se de testar se isso é realmente o que você deseja e espera.
Tenho uma experiência muito boa com o Tivoli Storage FlashCopy Manager (TSM DP para SQL Server) . O TSM DP permite backups de qualquer nó no grupo de disponibilidade. Backups redundantes são evitados armazenando os backups e logs em um nó TSM.