Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo discute o suporte ao 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 instâncias de cluster de failover Always On (FCIs) 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 estabelecer uma conexão com uma FCI ou ao listener de um grupo de disponibilidade, o SqlClient tenta estabelecer conexões com todos os endereços IP simultaneamente. 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:
ApplicationIntentMultiSubnetFailover
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+.
Conectar-se com MultiSubnetFailover
Sempre especifique MultiSubnetFailover=True ao se conectar à FCI ou ao listener de uma AG.
MultiSubnetFailover oferece um 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 rede secundária, o cliente tenta estabelecer agressivamente a conexão TCP.
A propriedade de conexão MultiSubnetFailover indica que a aplicação está a usar um AG ou um FCI e que a SqlClient tentará ligar-se ao banco de dados na instância primária do SQL Server tentando conectar-se 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 ligar-se a algo diferente de um AG ou FCI pode resultar num impacto negativo no desempenho e não é recomendado.
Use as seguintes diretrizes para se conectar a um servidor usando um dos recursos Always On:
Use a propriedade de ligação
MultiSubnetFailoverao ligar-se a uma única sub-rede ou multi-sub-rede; melhorará o desempenho de ambos.Para se conectar a um AG, especifique o listener 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
MultiSubnetFailoverpropriedade 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
Connect Timeoutpara acomodar o tempo de failover e reduza as tentativas de repetição de conexão do 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 apenas para leitura.
Uma ligaçã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 atualizar uma aplicação SqlClient que atualmente utiliza espelhamento de base de dados para um cenário de multi-subnet, deverá remover a propriedade de conexão Failover Partner e substituí-la por MultiSubnetFailover, definindo-a para True, e substituir o nome do servidor na cadeia de conexão por um listener 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=ReadOnly, o cliente solicita um trabalho de leitura ao se conectar a um banco de dados com AlwaysOn ativado. 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 com Always On habilitado.
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
ApplicationIntentpalavra-chave da cadeia de conexão deve ser definida comoReadOnly. - 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 encaminhamento só de leitura não se conectem todas à mesma réplica só de 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 o parâmetro da cadeia de conexão Data Source. Em vez disso, especifique o nome da instância somente leitura.
O roteamento de leitura única pode levar mais tempo do que a conexão com o primário, porque esse roteamento primeiramente se conecta ao primário e, depois, procura o melhor secundário legível disponível. Por isso, você deve aumentar o tempo limite de login.