Alta disponibilidade e recuperação de desastres com SqlClient

Baixar ADO.NET

Conecte-se a um endpoint de serviço estável em vez de uma réplica específica quando sua aplicação precisar sobreviver ao failover do servidor. Microsoft. O Data.SqlClient pode acelerar tentativas de conexão e solicitar roteamento somente de leitura, mas não faz com que uma transação em voo sobreviva a uma conexão quebrada.

Para a arquitetura do servidor, consulte grupos de disponibilidade Always On.

Conectar-se com o MultiSubnetFailover

Defina MultiSubnetFailover=true para endpoints TCP com suporte da família Microsoft SQL, incluindo listeners de AG, FCIs, Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure e Banco de Dados SQL no Microsoft Fabric. Use um nome de host e uma porta, não a descoberta de instância nomeada.

Server=tcp:<listener>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;

Substitua as configurações de autenticação do seu ambiente. O certificado deve validar o nome usado pelo cliente; veja Criptografia e validação de certificados.

Quando o Sistema de Nomes de Domínio (DNS) retorna vários endereços de Protocolo de Internet (IP), MultiSubnetFailover=true tenta conexões em paralelo e usa a primeira conexão bem-sucedida. Esse recurso reduz atrasos quando alguns endereços não são acessíveis ou não servem mais o banco de dados. Também acelera as retransmissões TCP. Para um endpoint de IP único, apenas um endereço é tentado.

A configuração não reduz o tempo de failover ou recuperação do banco de dados do servidor. Adote um Connect Timeout apropriado e uma política de repetição do aplicativo limitada para os requisitos de disponibilidade do seu serviço.

Compatibilidade de opções de conexão

O padrão para MultiSubnetFailover ainda é false na cadeia de conexão. Um switch AppContext de todo o processo pode habilitá-lo para todas as conexões. Prefira configuração explícita de conexão quando uma aplicação também usa alvos incompatíveis, como LocalDB ou espelhamento de banco de dados. Veja as mudanças do AppContext.

A Resolução Transparente de IP de Rede (TNIR) está obsoleta a partir do SqlClient 7.1. Não copie a palavra-chave TNIR para as strings de conexão .NET modernas. No .NET Framework, a configuração explícita do TNIR pode substituir o manuseio automático do driver para alguns endpoints e modos de autenticação. Não presuma que toda conexão sem MultiSubnetFailover sempre tente endereços estritamente sequenciais.

Reconecte após uma falha

Um failover pode quebrar uma conexão existente. Elimine a conexão com falha e abra uma nova contra o endpoint do serviço. Os recursos de recuperação de conexão e de retentativa têm limites; não reexecutam automaticamente uma operação de negócios interrompida.

1. Distinga um erro transitório de conectividade de uma credencial inválida, permissão negada ou falha de certificado.
2. Tentar estabelecer a conexão novamente com intervalos limitados e um limite total de tempo.
3. Repita uma operação com falha somente quando for possível determinar se ela foi concluída com êxito, ou quando a operação for projetada para ser idempotente.
4. Recrie o estado da transação e da sessão que pertenciam a uma sessão perdida.

Uma resposta perdida após um commit pode deixar o cliente em dúvida sobre se uma operação de escrita foi bem-sucedida. Tentar essa escrita sem proteção contra duplicados pode ser aplicada duas vezes. Veja lógica de novas tentativas configurável e pool de conexões do SQL Server.

Atualize para clusters de várias sub-redes a partir do espelhamento de banco de dados

O espelhamento de banco de dados está obsoleto. Failover Partnerpertence ao espelhamento de banco de dados; não é um endereço secundário AG nem uma configuração de grupo de failover do Azure.

Ao migrar um banco de dados espelhado para um AG:

1. Configure e verifique o ouvinte AG e o banco de dados no servidor.
2. Substitua o nome antigo do servidor pelo listener.
3. Remova Failover Partner.
4. Defina MultiSubnetFailover=true e especifique o banco de dados AG.
5. Exercite o comportamento de failover e tente novamente antes de implementar a mudança.

SqlClient rejeita Failover Partner combinado com MultiSubnetFailover=true. Apenas configurar MultiSubnetFailover=false não configura o espelhamento; um par espelhado válido e um banco de dados ainda são necessários. Um parceiro de espelhamento definido pelo servidor também é incompatível com o failover de múltiplas sub-redes.

Especificar a intenção do aplicativo

Defina ApplicationIntent=ReadOnly para solicitar uma carga de trabalho de leitura em um banco de dados de AG:

Server=tcp:<listener>,1433;Database=<database>;Integrated Security=true;Encrypt=true;TrustServerCertificate=false;MultiSubnetFailover=true;ApplicationIntent=ReadOnly;

As políticas de conexão primária e secundária do AG determinam se a carga de trabalho solicitada é aceita. Um primário configurado para rejeitar cargas de trabalho de apenas leitura pode rejeitar esta conexão. Um secundário configurado para acesso somente leitura rejeita uma conexão de leitura e gravação.

ApplicationIntent não transforma um banco de dados em somente leitura, não substitui permissões nem roteia bancos de dados somente leitura comuns. Conceda permissões de somente leitura quando o aplicativo não deve poder gravar.

Roteamento somente para leitura

Para o roteamento somente leitura do AG, defina todas as configurações a seguir:

• Conecte-se ao AG listener.
• Defina Database como um banco de dados no AG.
• Defina ApplicationIntent=ReadOnly.
• Configure a réplica secundária para leitura e a URL de roteamento somente leitura.
• Configurar a lista de roteamento de somente leitura da réplica principal.

O cliente primeiro entra em contato com o servidor principal por meio do listener e, em seguida, se conecta ao destino roteado. Permita acesso à rede e nomes válidos de certificados para ambas as fases de conexão. O roteamento pode adicionar tempo de conexão.

Aberturas distintas podem acessar diferentes réplicas de leitura à medida que a configuração de roteamento e a disponibilidade mudam. Um pool aberto pode reutilizar uma conexão existente em vez de realizar o roteamento novamente. Conectar-se diretamente a uma instância secundária seleciona essa instância, mas contorna o roteamento baseado em listener e seu comportamento de failover.

SqlDependency não é suportado em réplicas secundárias somente para leitura. Revise separadamente a versão do SQL Server e os requisitos de implantação para recursos como transações distribuídas; MultiSubnetFailover sozinho não estabelece o suporte deles.

SQL do Azure e Microsoft Fabric

Para o SQL do Azure, use o endpoint configurado do serviço, incluindo o listener do grupo de failover, quando aplicável. Não use Failover Partner para um grupo de failover do SQL do Azure. Failover gerenciado por serviços difere de configurar um SQL Server AG por conta própria.

Para banco de dados SQL no Microsoft Fabric:

• Use a cadeia de conexão do banco de dados com a autenticação do Microsoft Entra e MultiSubnetFailover=true.
• Use o ponto de extremidade de análise de SQL separado para a carga de trabalho analítica somente leitura. Não presuma que ApplicationIntent=ReadOnly redireciona o endpoint de gravação do banco de dados.
• Não configure Failover Partner nem o roteamento do SQL Server AG para o serviço de banco de dados.
• Considere a política de conexão atual Default: permita o tráfego de saída pela porta TCP 1433 para os gateways e pelas portas 11000 a 11999 para os endereços regionais do SQL do Azure.

Fabric oferece redundância automática de zonas. A georreplicação ativa, os grupos de failover e a georrestauração não têm suporte no momento para o banco de dados SQL no Fabric. O Coordenador de Transações Distribuídas da Microsoft, a biblioteca de cliente de banco de dados elástico e a consulta elástica também não têm suporte. Veja Conectar-se a um banco de dados SQL no Fabric e Limitações do banco de dados SQL no Fabric.

Conteúdo relacionado

• Recursos do SQL Server e ADO.NET
• Opções de conexão
• Solucionar problemas no SqlClient