"AlwaysOn" nem sempre é "Always On?"

Criamos um cluster de failover do Windows e adicionamos duas instâncias do SQL Server como nós de um cluster de failover do SQL Server.

Definimos os servidores para usar "AlwaysOn Availability Groups" no SQL Configuration Manager.

Para testar um failover, carreguei e executei uma consulta longa e reduzi o nó ativo usando o Gerenciador de Cluster de Failover para interromper o serviço de cluster no nó ativo.

A consulta foi interrompida sem conexão e o servidor ficou indisponível por cerca de 20 segundos antes de o nó ser drenado e o novo nó assumir o controle.

Eu fiz isso errado? Como eu deveria ter configurado isso para que houvesse pouca ou nenhuma perda de conectividade?

O AlwaysOn nem sempre está ativado?

Você tem um monte de perguntas diferentes aqui.

P: O que é a coisa "Always On"?

A Microsoft usa esse nome de marca (que foi escrito sem espaço antes de 2016) para descrever dois recursos diferentes:

• FCIs (Failover Clustered Instances) - o que seu avô costumava chamar de cluster ativo / passivo
• Grupos de disponibilidade (AGs) - como o espelhamento de banco de dados, mas funciona com grupos de bancos de dados em alguns casos (mas não os bancos de dados do sistema)

Use esses termos para descrever qual recurso Always On específico você está usando.

P: Em um failover, ele estará sempre ativado?

Nem FCIs nem AGs estão realmente sempre ativos. Durante um failover, suas transações em execução falham e as tentativas de conexão podem falhar por 5 a 60 segundos (ou mais). Cabe a você criar uma lógica de repetição simples em seus aplicativos ou ferramentas de recursos degradadas, como o Stack Overflow .

P: Como faço para configurar o Always On?

Varia drasticamente com base em:

• Qual recurso de AO você está usando (FCIs ou AGs)
• O número de nós no cluster
• Como você deseja lidar com o quorum (votação)
• Se você estiver usando failover automático por meio de um nome de ouvinte ou computador virtual

Essas são grandes decisões que envolvem muito trabalho de arquitetura. Para detalhes mais detalhados, inclua os detalhes acima e poderemos contar mais sobre como configurá-lo.

P: Não é apenas uma questão de marcar a caixa Always On?

Não.

Você pode confundir AGs "Always ON" (Grupos de Disponibilidade) com FCIs (Instâncias de Cluster de Failover), os quais dependem do WSFC (Cluster de Failover do Windows Server).

Clicar em 'sempre ativado' não garante que você agora tenha uma configuração de AG. Você precisa definir assinaturas assíncronas, sincronizadas, de leitura / failover, definir prioridade e tomar outras considerações, como o aplicativo suporta essa configuração. Por exemplo, seu aplicativo pode usar transações MSDTC entre bancos de dados, que não são suportadas e podem causar corrupção irrecuperável que requer uma restauração de backup.

No momento, o que você está enfrentando é um failover da FCI. Isto é normal. Isso interrompe os serviços em um nó e inicia os serviços no outro nó. Isso funciona no nível INSTANCE. Uma solução AG é configurada por banco de dados e os serviços estão em execução nos dois nós. O SQL usa as APIs do WSFC para manter os dados sincronizados nas réplicas, e o banco de dados realiza failover nessa réplica; note que não a instância.

Você pode fazer muitos testes sobre isso antes de implantar na produção.

Meu método preferido de testar um failover em um AG é simplesmente desconectar o primário atual. Basta desligá-lo, desligá-lo do console, puxar sua rede, matar o serviço SQL com uma bala de prata, qualquer que seja. Você não deve testá-lo a partir de algo semelhante a GUI, porque não é assim que o caos funciona.

_{Resposta do wiki da comunidade :}

Esse é o comportamento normal e esperado para um cluster.

É de responsabilidade do aplicativo lidar com a desconexão normalmente. Quaisquer transações em andamento serão perdidas, pois apenas as transações confirmadas são replicadas entre os servidores.