Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo aborda o suporte do Microsoft SqlClient Provedor de Dados para SQL Server à alta disponibilidade e à recuperação de desastres, incluindo os Grupos de Disponibilidade Always On. Para mais informações, veja os grupos de disponibilidade Always On.
Agora você pode especificar o ouvinte de grupo de disponibilidade de um grupo de disponibilidade e um grupo de disponibilidade de recuperação de desastres (HADR) (AG) ou uma instância de cluster de failover (FCI) na propriedade de conexão. Se uma aplicação SqlClient se conecta a um banco de dados Always On que faz failover, a conexão original é interrompida e a aplicação deve abrir uma nova conexão para continuar o trabalho após o failover.
Se você não se conectar a um ouvinte de grupo de disponibilidade ou FCI, e se vários endereços IP forem associados com um nome de host, o SqlClient vai iterar em sequência por todos os endereços IP associados à entrada DNS. Esse processo 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). Quando você se conecta a um listener do AG ou a um FCI, o SqlClient tenta estabelecer conexões com todos os endereços IP em paralelo. Se uma tentativa de conexão obtiver êxito, o driver descartará as tentativas de conexão pendentes.
Observação
O aumento do tempo limite de conexão e a implementação de lógica de repetição de conexão aumentarão a probabilidade de um aplicativo se conectar a um grupo de disponibilidade. Além disso, como uma conexão pode falhar por causa de um failover, você deve implementar uma lógica de nova tentativa de conexão, repetindo a tentativa após uma falha até que a conexão seja restabelecida.
As seguintes propriedades de conexão são compatíveis com o Provedor de Dados do Microsoft SqlClient para SQL Server:
ApplicationIntentMultiSubnetFailover
você pode modificar programaticamente essas palavras-chave de cadeia de conexão com:
Conectando-se ao MultiSubnetFailover
Sempre especifique MultiSubnetFailover=True quando você se conecta a um endpoint TCP da família Microsoft SQL. Essa configuração se aplica a ouvintes de grupos de disponibilidade, instâncias de cluster de failover e pontos de extremidade multi-IP, como Banco de Dados SQL do Azure, Instância Gerenciada do SQL do Azure e Banco de Dados SQL no Microsoft Fabric.
Quando o nome do servidor na sua cadeia de conexão é resolvido em mais de um endereço IP, MultiSubnetFailover=True faz o SqlClient abrir conexões para todos esses endereços ao mesmo tempo e usar o primeiro a responder. Sem ele, o SqlClient testa os endereços um de cada vez. Um endereço que não responde fica bloqueado até que o tempo limite de conexão TCP do sistema operacional expire, o que pode esgotar Connect Timeout antes que o SqlClient alcance um endereço que responda. Após um failover, o endereço que o SqlClient tenta primeiro pode ser aquele que não atende mais ao banco de dados, então uma conexão que teria sucesso contra outro endereço falha com um timeout.
MultiSubnetFailover=True muda a rapidez com que o cliente encontra a réplica que atende ao banco de dados. Isso não muda o tempo que o servidor leva para fazer failover. Com essa configuração habilitada, o SqlClient também repete as tentativas de conexão TCP em intervalos menores que os intervalos padrão de retransmissão de TCP do sistema operacional, o que acelera a reconexão tanto para grupos de disponibilidade de sub-rede única e de várias sub-redes quanto para instâncias de cluster de failover.
MultiSubnetFailover=True é seguro em alvos de IP único. Quando o DNS resolve para um único endereço, o SqlClient faz uma única tentativa de conexão, então a configuração não custa nada quando não é necessária.
Para obter mais informações sobre as palavras-chave de cadeia de conexão no SqlClient, confira ConnectionString. Para obter orientações sobre a configuração relacionada à Resolução Transparente de IP de Rede (TNIR) no .NET Framework e para solucionar conexões lentas causadas por nomes DNS com vários IPs, consulte Como desabilitar a Resolução Transparente de IP de Rede e Longos atrasos de conexão com tempo limite no handshake de pré-logon.
Use as seguintes diretrizes ao configurar MultiSubnetFailover:
Defina
MultiSubnetFailover=True.Para conectar-se a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade como o servidor em sua cadeia de conexão.
Você não pode usar
MultiSubnetFailoverquando se conecta a uma instância nomeada.Você não pode usar
MultiSubnetFailoverpor um protocolo que não seja TCP.Conectar a uma instância do SQL Server configurada com mais de 64 endereços IP causa uma falha de conexão.
Você não pode usar
MultiSubnetFailovercom espelhamento de banco de dados. Para saber mais, confira Atualizar para usar clusters de várias sub-redes a partir do espelhamento de banco de dados. O espelhamento de banco de dados está obsoleto em todas as versões suportadas do SQL Server. Use Grupos de disponibilidade AlwaysOn em vez disso.O comportamento de um aplicativo que usa a propriedade de conexão
MultiSubnetFailovernã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 compensar o tempo de failover e reduzir as tentativas de reconexão do aplicativo.Não há suporte para transações distribuídas.
Se o roteamento de somente leitura não estiver em vigor, a conexão com um local com réplica secundária falhará nas seguintes situações:
Se o local de réplica secundário não for configurado para aceitar conexões.
Se um aplicativo usar
ApplicationIntent=ReadWrite(abordado abaixo) e o local da réplica secundária estiver configurado para acesso somente leitura.
O SqlDependency não é compatível com réplicas secundárias somente leitura.
Uma conexão falhará se uma réplica primária estiver configurada para rejeitar cargas de trabalho de somente leitura e a string de conexão contiver ApplicationIntent=ReadOnly.
Como atualizar para usar clusters de várias sub-redes com espelhamento de banco de dados
Um erro de conexão (ArgumentException) ocorrerá se as palavras-chave de conexão MultiSubnetFailover e Failover Partner estiverem presentes na cadeia de conexão ou se MultiSubnetFailover=True e um protocolo diferente de TCP forem usados. Um erro (SqlException) também ocorrerá se MultiSubnetFailover for usada e o SQL Server retornar uma resposta de parceiro de failover indicando que ela 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 com várias sub-redes, deverá remover a propriedade de conexão Failover Partner e substituí-la por MultiSubnetFailover definida como True, além de substituir o nome do servidor na string de conexão por um listener de grupo de disponibilidade. Se a 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á o espelhamento de banco de dados.
O driver retornará um erro se você usar espelhamento de banco de dados na réplica primária no grupo de disponibilidade e se MultiSubnetFailover=True estiver definido na cadeia de conexão que se conecta a uma réplica primária, e não ao ouvinte de um grupo de disponibilidade.
Especificando a intenção do aplicativo
Quando você define ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura quando você conecta a um banco de dados habilitado pelo Always On. O servidor impõe a intenção no momento da conexão e durante uma instrução USE do banco de dados, mas somente para um banco de dados habilitado para Always On.
A palavra-chave ApplicationIntent não funciona com bancos de dados legados e somente de leitura.
Um banco de dados pode permitir ou impedir cargas de trabalho de leitura no banco de dados de destino do Always On. (Isso é feito com a cláusula ALLOW_CONNECTIONS das instruções PRIMARY_ROLE e SECONDARY_ROLETransact-SQL.)
A palavra-chave ApplicationIntent é usada para ativar o roteamento de somente leitura.
Roteamento somente para leitura
O roteamento somente leitura é um recurso que pode assegurar a disponibilidade de uma réplica somente leitura de um banco de dados. Para habilitar o roteamento somente de leitura:
Você deve conectar-se a um ouvinte de grupo de disponibilidade AlwaysOn.
A palavra-chave de cadeia de conexão
ApplicationIntentdeve ser definida comoReadOnly.O Grupo de Disponibilidade deve ser configurado pelo administrador do banco de dados para habilitar o roteamento somente para leitura.
É possível que várias conexões que usam roteamento de somente leitura não se conectem todas à mesma réplica de somente leitura. Alterações na sincronização de banco de dados ou alterações na configuração de roteamento de servidor podem resultar em conexões de cliente com réplicas somente leitura diferentes. Para garantir que todas as solicitações somente leitura conectem-se à mesma réplica somente leitura, não transmita um ouvinte de grupo de disponibilidade à palavra-chave de cadeia de conexão Data Source. Em vez disso, especifique o nome da instância de somente leitura.
O roteamento somente leitura pode demorar mais tempo do que a conexão ao primário porque o roteamento somente leitura conecta-se primeiramente ao primário e depois procura o melhor secundário legível disponível. Por isso, você deve aumentar seu tempo limite de logon.