Precisamos conhecer os riscos/armadilhas de uma configuração específica do AlwaysOn. Queremos uma configuração AlwaysOn com os seguintes requisitos (abaixo).
Minha pergunta é: esta é uma configuração de som ou estou perdendo algo vital ou há um eixo que invalida esta configuração?
SQL Server de origem: executado na máquina virtual Um aplicativo de farmácia se conecta a um banco de dados principal com acesso total
SQL Server de destino/réplica: é executado na máquina virtual B O acesso da Microsoft conecta-se ao banco de dados de réplica (acima) com acesso somente leitura para executar muitos relatórios
Testemunha: Compartilhamento de arquivos
Nota do white paper da Microsoft (queremos conectar desta forma para ambos os nós--node\instance-name versus listener):
Você pode se conectar à réplica secundária usando node\instance-name: Configure a réplica primária para PRIMARY_ROLE (ALLOW_CONNECTIONS = READ_WRITE) e use 'ApplicationIntent=ReadOnly' em sua string de conexão para relatar a carga de trabalho. Nesse caso, se você conectar por engano sua carga de trabalho de relatórios a um nó físico que já esteja em execução como uma réplica primária, a conexão será negada.
Failover: Failover é um processo manual. Se o A cair, ativaríamos manualmente o servidor de réplica B como o servidor principal - de forma assíncrona para iniciantes - mesmo que houvesse algum espaço para perda de dados.
A única preocupação possível em sua configuração é a opção Modo de Disponibilidade e Failover. Se suas máquinas virtuais estiverem no mesmo datacenter ou relativamente próximas geograficamente com uma boa conexão entre elas, você deve usar o modo Synchronous-commit e Automatic Failover para obter o melhor cenário de recuperação sem perda de dados e tempo de inatividade mínimo, especialmente se falhar durante um vezes, pode ser difícil conseguir que alguém faça o failover manualmente.
Se eles estiverem significativamente separados geograficamente e a conectividade não for 'boa' de maneira confiável, sua configuração está correta, a menos que a perda de dados seja considerada catastrófica. A rota assíncrona é principalmente para uso quando o desempenho é esporádico ou longe de ser garantido.
Embora especificar a conexão tenha algum valor, pode ser um exagero em tal configuração se, por algum motivo, seu aplicativo de relatórios perder a conectividade com a réplica secundária. Não há nenhuma razão para que ela não possa relatar a réplica primária além de possíveis problemas de desempenho, mas isso pode ser uma razão válida o suficiente para garantir que a primária negue a conexão.