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

Baixar ADO.NET

Este artigo discute o Microsoft SqlClient Provedor de Dados para suporte ao SQL Server para alta disponibilidade e recuperação de desastres, incluindo Grupos de Disponibilidade Sempre Ligados. Para mais informações, veja os grupos de disponibilidade Always On.

Agora você pode especificar o ouvinte do grupo de disponibilidade de um grupo de disponibilidade e recuperação de desastres (HADR) ou 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 múltiplos endereços IP estiverem associados a um nome de host, o SqlClient itera sequencialmente 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). 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 devido a um failover, você deve implementar lógica de repetição de conexão, repetindo uma conexão com falha até se reconectar.

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 de IP único. 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 tenta agressivamente a 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 uma conexão, o cliente tenta novamente as tentativas de conexão TCP mais rápido 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. Ele se aplica tanto a Grupos de Disponibilidade de uma única e múltiplas 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 orientações sobre a configuração relacionada de Resolução IP de Rede Transparente (TNIR) no .NET Framework, e para solucionar conexões lentas causadas por nomes DNS multi-IP, veja Desabilitando a Resolução de IP de Rede Transparente e Atrasos Longos de Conexão com tempo de espera de handshake pré-login.

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 conectar-se a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade como o servidor em 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 acomodar o tempo de failover e reduza as tentativas de repetição da conexão do aplicativo.

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

Se o roteamento somente leitura não estiver em ação, conectar-se a um local de réplica secundária apresentará falha 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 somente leitura e a cadeia 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 o espelhamento de banco de dados em um cenário de várias sub-redes, deverá remover a propriedade de conexão Failover Partner e substituí-la por MultiSubnetFailover definido como True e substituir o nome do servidor da cadeia de conexão por um ouvinte 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 no AG e se MultiSubnetFailover=True for usado na cadeia de conexão que se conecta a um banco de dados primário, e não a um ouvinte de grupo de disponibilidade.

Especificando a intenção do aplicativo

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

A palavra-chave ApplicationIntent não funciona com bancos de dados somente leitura de versões anteriores.

Um banco de dados pode permitir ou não cargas de trabalho de leitura no banco de dados Always On de destino. (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 habilitar o roteamento somente leitura.

Roteamento somente 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 roteamento somente 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 de banco de dados para permitir o roteamento somente leitura.

É possível que nem todas as várias conexões que usam roteamento somente leitura se conectem à mesma réplica 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 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.

Próximas etapas

  • Last updated on