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

  • Artigo

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

Agora você pode especificar um ouvinte de um grupo de disponibilidade ou o nome de uma FCI na propriedade de conexão. Se um aplicativo SqlClient está conectado a um banco de dados que realiza 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 conectado a um AG ou FCI, e se houver vários endereços IP associados a um nome de host, o SqlClient percorrerá sequencialmente todos os endereços IP associados à entrada DNS. Isso pode demorar muito se o primeiro endereço IP retornado pelo servidor DNS não estiver associado a nenhuma NIC (placa de interface de rede). Ao se conectar a um 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 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 foram adicionadas ao SqlClient no .NET Framework 4.5:

  • ApplicationIntent

  • MultiSubnetFailover

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

Observação

Definir MultiSubnetFailover como true não é necessário com as versões 4.6.1 e posteriores do .NET Framework. É necessário no .NET Core e no .NET 5+.

Conectando-se ao MultiSubnetFailover

Sempre especifique MultiSubnetFailover=True ao se conectar à FCI ou ao ouvinte de um AG. MultiSubnetFailover permite o 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 ou várias sub-redes. Durante um failover de várias sub-redes, o cliente tentará conexões em paralelo. Durante um failover de sub-rede, o cliente repete agressivamente a conexão TCP.

A propriedade de conexão MultiSubnetFailover indica que o aplicativo está usando AG ou FCI e que o 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 repete as tentativas de 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 um AG ou FCI e é aplicável a AGs e FCIs de várias sub-redes.

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

A especificação de MultiSubnetFailover=True ao conectar-se a algo que não seja um AG ou FCI poderá resultar em um impacto de desempenho negativo significativo, para o qual não há suporte.

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

  • 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 AG, especifique o ouvinte do grupo de disponibilidade como servidor na cadeia de caracteres 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.

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 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 leitura ao se conectar a um banco de dados habilitado para AlwaysOn. 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 AlwaysOn de destino. (Isso é feito com a cláusula ALLOW_CONNECTIONS das instruções PRIMARY_ROLE e SECONDARY_ROLETransact-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:

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

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

  3. 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.

Confira também