Partilhar via

Suporte SqlClient para alta disponibilidade e recuperação de desastres

  • Artigo

Este artigo discute o suporte a SqlClient (adicionado no .NET Framework 4.5) para alta disponibilidade e recuperação de desastres com os recursos Always On: grupos de disponibilidade Always On (AGs) e FCIs (instâncias de cluster de failover) Always On com o SQL Server 2012 ou posterior.

Agora você pode especificar um ouvinte de grupo de disponibilidade ou o nome de uma FCI na propriedade de conexão. Se um aplicativo SqlClient estiver conectado a um banco de dados que faça failover, a conexão original será interrompida e o aplicativo deverá abrir uma nova conexão para continuar o trabalho após o failover.

Se você não estiver se conectando a um AG ou FCI, e se vários endereços IP estiverem associados a um nome de host, o SqlClient iterará sequencialmente através de todos os endereços IP associados à entrada DNS. Isso pode ser demorado se o primeiro endereço IP retornado pelo servidor DNS não estiver vinculado a nenhuma placa de interface de rede (NIC). Ao conectar uma FCI ou ao ouvinte de um grupo de disponibilidade, o SqlClient tenta estabelecer conexões com todos os endereços IP em paralelo. Se uma tentativa de conexão for bem-sucedida, o driver descartará todas as tentativas de conexão pendentes.

Nota

Aumentar o tempo limite de conexão e implementar a lógica de repetição de conexão aumentará a probabilidade de um aplicativo se conectar a um grupo de disponibilidade. Além disso, como uma conexão pode falhar devido a um failover, você deve implementar a lógica de repetição de conexão, tentando novamente uma conexão com falha até que ela se reconecte.

As seguintes propriedades de conexão foram adicionadas ao SqlClient no .NET Framework 4.5:

  • ApplicationIntent
  • MultiSubnetFailover

Você pode modificar programaticamente essas palavras-chave de cadeia de conexão com:

Nota

A configuração MultiSubnetFailover como true não é necessária com o .NET Framework versões 4.6.1 e posteriores. É necessário no .NET Core e no .NET 5+.

Conectando-se com MultiSubnetFailover

Sempre especifique MultiSubnetFailover=True ao se conectar à FCI ou ao ouvinte de uma AG. MultiSubnetFailover permite failover mais rápido para todos os AGs e/ou FCIs no SQL Server 2012 ou posterior e reduz significativamente o tempo de failover para topologias Always On de uma e várias sub-redes. Durante um failover de várias sub-redes, o cliente tenta conexões em paralelo. Durante um failover de sub-rede, o cliente tenta agressivamente a conexão TCP.

A MultiSubnetFailover propriedade connection indica que o aplicativo está usando um AG ou FCI e que SqlClient tentará se conectar ao banco de dados na instância primária do SQL Server tentando se conectar a todos os endereços IP. Quando MultiSubnetFailover=True é especificado para uma conexão, o cliente tenta novamente a conexão TCP mais rápido do que os intervalos de retransmissão TCP padrão do sistema operacional. Isso permite uma reconexão mais rápida após o failover de uma AG ou FCI, e é aplicável a AGs e FCIs de sub-rede única e múltipla.

Para obter mais informações sobre palavras-chave de cadeia de conexão em SqlClient, consulte ConnectionString.

Especificar MultiSubnetFailover=True ao se conectar a algo diferente de uma AG ou FCI pode resultar em um impacto negativo no desempenho e não é suportado.

Use as seguintes diretrizes para se conectar a um servidor usando um dos recursos Always On:

  • Use a propriedade connection ao se conectar a uma única sub-rede ou multi-sub-rede, isso melhorará o MultiSubnetFailover desempenho de ambos.

  • Para se conectar a um AG, especifique o ouvinte do grupo de disponibilidade como o servidor na cadeia de conexão.

  • A conexão com uma instância do SQL Server configurada com mais de 64 endereços IP causará uma falha de conexão.

  • O comportamento de um aplicativo que usa a MultiSubnetFailover propriedade de conexão não é afetado com base no tipo de autenticação: Autenticação do SQL Server, Autenticação Kerberos ou Autenticação do Windows.

  • Aumente o valor de para acomodar o tempo de failover e reduza as tentativas de repetição de conexão do Connect Timeout aplicativo.

  • Não há suporte para transações distribuídas.

Se o roteamento somente leitura não estiver em vigor, a conexão com um local de réplica secundário falhará nas seguintes situações:

  • Se o local da réplica secundária não estiver configurado para aceitar conexões.

  • Se um aplicativo usar ApplicationIntent=ReadWrite (discutido abaixo) e o local da réplica secundária estiver configurado para acesso somente leitura.

SqlDependency não é suportado em réplicas secundárias somente leitura.

Uma conexão falhará se uma réplica primária estiver configurada para rejeitar cargas de trabalho somente leitura e a cadeia de conexão contiver ApplicationIntent=ReadOnly.

Atualizando para usar clusters de várias sub-redes a partir do espelhamento de banco de dados

Um erro de conexão (ArgumentException) ocorrerá se as MultiSubnetFailover palavras-chave e Failover Partner conexão estiverem presentes na cadeia de conexão ou se MultiSubnetFailover=True e um protocolo diferente de TCP for usado. Um erro (SqlException) também ocorrerá se MultiSubnetFailover for usado e o SQL Server retornar uma resposta de parceiro de failover indicando que faz parte de um par de espelhamento de banco de dados.

Se você atualizar um aplicativo SqlClient que atualmente usa espelhamento de banco de dados para um cenário de várias sub-redes, deverá remover a Failover Partner propriedade de conexão e substituí-la por MultiSubnetFailover set to True e substituir o nome do servidor na cadeia de conexão por um ouvinte de grupo de disponibilidade. Se uma cadeia de conexão usar Failover Partner e MultiSubnetFailover=True, o driver gerará um erro. No entanto, se uma cadeia de conexão usar Failover Partner e MultiSubnetFailover=False (ou ApplicationIntent=ReadWrite), o aplicativo usará espelhamento de banco de dados.

O driver retornará um erro se o espelhamento de banco de dados for usado no banco de dados primário no AG e se MultiSubnetFailover=True for usado na cadeia de conexão que se conecta a um banco de dados primário em vez de a um ouvinte de grupo de disponibilidade.

Especificando a intenção do aplicativo

Quando ApplicationIntent=ReadOnlyo , o cliente solicita uma carga de trabalho de leitura ao se conectar a um banco de dados habilitado para AlwaysOn. O servidor imporá a intenção no momento da conexão e durante uma instrução de banco de dados USE, mas somente para um banco de dados habilitado para Always On.

A ApplicationIntent palavra-chave não funciona com bancos de dados legados e somente leitura.

Um banco de dados pode permitir ou não permitir cargas de trabalho de leitura no banco de dados AlwaysOn de destino. (Isso é feito com a ALLOW_CONNECTIONS cláusula das PRIMARY_ROLE instruções e SECONDARY_ROLETransact-SQL.)

A ApplicationIntent palavra-chave é usada para habilitar o roteamento somente leitura.

Roteamento somente leitura

O roteamento somente leitura é um recurso que pode garantir a disponibilidade de uma réplica somente leitura de um banco de dados. Para habilitar o roteamento somente leitura:

  • Você deve se conectar a um ouvinte do grupo de disponibilidade do Grupo de Disponibilidade AlwaysOn.
  • A ApplicationIntent palavra-chave da cadeia de conexão deve ser definida como ReadOnly.
  • O Grupo de Disponibilidade deve ser configurado pelo administrador do banco de dados para habilitar o roteamento somente leitura.

É possível que várias conexões usando roteamento somente leitura não se conectem todas à mesma réplica somente leitura. Alterações na sincronização do banco de dados ou alterações na configuração de roteamento do servidor podem resultar em conexões de cliente para diferentes réplicas somente leitura. Para garantir que todas as solicitações somente leitura se conectem à mesma réplica somente leitura, não passe um ouvinte do grupo de disponibilidade para a Data Source palavra-chave da cadeia de conexão. Em vez disso, especifique o nome da instância somente leitura.

O roteamento somente leitura pode levar mais tempo do que a conexão com o primário porque o roteamento somente leitura primeiro se conecta ao primário e, em seguida, procura o melhor secundário legível disponível. Por isso, você deve aumentar o tempo limite de login.

Consulte também