Suporte do SqlClient para alta disponibilidade e recuperação de desastre

Baixar ADO.NET

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 listener do grupo de disponibilidade de um grupo de disponibilidade (AG) de alta disponibilidade e recuperação de desastres (HADR) ou de 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 a um FCI, e se vários endereços IP estiverem associados a um nome de host, o SqlClient percorre sequencialmente todos os endereços IP associados ao registro 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). Ao se conectar a um ouvinte AG ou FCI, o SqlClient tenta estabelecer conexões para 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:

  • ApplicationIntent

  • MultiSubnetFailover

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

Conectando-se ao MultiSubnetFailover

Sempre especifique MultiSubnetFailover=True ao conectar 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 endpoints multi-IP, como Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure e SQL Database no Microsoft Fabric. A propriedade também é segura em alvos com um único IP. MultiSubnetFailover permite um failover mais rápido para todos os Grupos de Disponibilidade e Instâncias de Cluster de Failover, além de reduzir significativamente o tempo de failover para topologias Always On de uma e múltiplas sub-redes. Durante um failover de várias sub-redes, o cliente tenta conexões em paralelo. Durante um failover de sub-rede, ele repete agressivamente as tentativas de conexão TCP. MultiSubnetFailover não é suportado quando você se conecta a uma instância nomeada ou por um protocolo que não seja TCP.

A MultiSubnetFailover propriedade de conexão indica que o SqlClient deve tentar se conectar ao banco de dados na instância principal do SQL Server conectando-se a todos os endereços IP em paralelo. Quando você especifica MultiSubnetFailover=True para uma conexão, o cliente repete as tentativas de conexão TCP mais rapidamente do que os intervalos padrão de retransmissão TCP do sistema operacional. Essa configuração permite uma reconexão mais rápida após o failover de um Grupo de Disponibilidade Sempre Ativo ou de uma Instância de Cluster de Failover Sempre Ativa. Aplica-se tanto a Grupos de Disponibilidade de sub-rede única e de várias sub-redes quanto a Instâncias de Cluster de Failover.

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 Desabilitando 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:

  • Use a propriedade de conexão MultiSubnetFailover para conectar-se a uma ou várias sub-redes; isso melhorará o desempenho de ambos.

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

  • Conectar-se a 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 propriedade de conexão MultiSubnetFailover 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 Timeout para 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 (discutido abaixo) e se o local da réplica secundária estiver configurado para acesso somente para leitura.

SqlDependency não tem suporte em réplicas secundárias somente de 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 a partir do 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 o espelhamento de banco de dados for usado no banco de dados primário do grupo de disponibilidade (AG) e se MultiSubnetFailover=True for usado na cadeia de conexão para se conectar a um banco de dados primário, em vez de a um listener do grupo de disponibilidade.

Especificando a intenção do aplicativo

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

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 ALLOW_CONNECTIONS cláusula das instruções PRIMARY_ROLE e das declarações SECONDARY_ROLE Transact-SQL.)

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

Roteamento somente para leitura

O roteamento de 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 de leitura:

  • Você deve conectar-se a um ouvinte de grupo de disponibilidade AlwaysOn.

  • A palavra-chave de cadeia de conexão ApplicationIntent deve ser definida como ReadOnly.

  • 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 de somente leitura se conectem à mesma réplica de somente leitura, não informe um listener de grupo de disponibilidade para a palavra-chave da 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.

Conteúdo relacionado

  • Last updated on