Alta disponibilidade e recuperação de desastre

Baixar Driver ODBC

O driver Microsoft ODBC para SQL Server suporta grupos de disponibilidade Always On. Para obter mais informações sobre os grupos de disponibilidade Always On, confira:

Você pode especificar o ouvinte de um determinado grupo de disponibilidade na cadeia de conexão. Se um aplicativo ODBC se conecta a um banco de dados em um grupo de disponibilidade que faça failover, a conexão original é interrompida. O aplicativo deverá abrir uma nova conexão para continuar o trabalho após o failover.

Sem MultiSubnetFailover=Yes, o fallback multi-IP herdado do driver pode ser lento quando o primeiro endereço IP resolvido não pode ser alcançado. Para obter mais informações sobre o comportamento de fallback do Windows, consulte Usar resolução de IP da rede transparente com o driver ODBC.

Ao se conectar a um ouvinte do grupo de disponibilidade usando MultiSubnetFailover=Yes, o driver tenta conexões com todos os endereços IP resolvidos em paralelo. Se uma tentativa de conexão obtiver êxito, o driver descartará as tentativas de conexão pendentes.

Note

Como uma conexão pode falhar devido a um failover de grupo de disponibilidade, você deve implementar a lógica de repetição de conexão. Repetir uma conexão com falha até que ela se reconecte. Aumentar o tempo limite de conexão e implementar a lógica de repetição de conexão aumentará a probabilidade de se conectar a um grupo de disponibilidade.

Conectar-se com o MultiSubnetFailover

Definido MultiSubnetFailover=Yes quando o alvo é Banco de Dados SQL do Azure, Instância Gerenciada do SQL do Azure, banco de dados SQL no Microsoft Fabric, um ouvinte de grupo de disponibilidade ou uma instância de cluster de failover. MultiSubnetFailover permite uma recuperação de failover mais rápida ao fazer com que o driver tente conexões TCP com todos os endereços IP resolvidos em paralelo e use a primeira conexão bem-sucedida.

Essa propriedade de conexão também reduz significativamente o tempo de failover para topologias AlwaysOn únicas e com várias sub-redes. Durante um failover de várias sub-redes, o cliente tenta conexões em paralelo. Durante um failover de sub-rede, o driver repete agressivamente a conexão TCP.

A propriedade de conexão MultiSubnetFailover indica que o aplicativo está sendo implantado em uma topologia na qual o nome de host de destino pode ser resolvido para mais de um ponto de extremidade. O driver tenta se conectar ao banco de dados na instância primária do SQL Server ao tentar se conectar a todos os endereços IP.

Quando você conecta usando MultiSubnetFailover=Yes, 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. MultiSubnetFailover=Yes permite uma reconexão mais rápida após o failover de um grupo de disponibilidade AlwaysOn ou uma instância de cluster de failover AlwaysOn. MultiSubnetFailover=Yes se aplica tanto a grupos de disponibilidade e instâncias de cluster de failover únicos quanto de várias sub-redes.

MultiSubnetFailover=Yes é seguro em alvos de IP único. Quando o DNS resolve para um endereço, MultiSubnetFailover=Yes não cria tentativas adicionais de conexão paralela.

Recomendações

Quando você se conecta a um destino altamente disponível ou de vários pontos de extremidade (Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, Banco de Dados SQL no Microsoft Fabric, um ouvinte do grupo de disponibilidade ou uma instância do cluster de failover):

  • Especifique MultiSubnetFailover=Yes. Essa é a configuração recomendada para esses alvos, e é seguro deixar ativado quando o alvo resolve para um único endereço IP, porque o driver então faz uma única tentativa de conexão.

  • Especifique o ouvinte do grupo de disponibilidade como o servidor em sua cadeia de conexão.

  • Você não pode usar MultiSubnetFailover=Yes por um protocolo que não seja TCP.

  • Não é permitido se conectar a uma instância do SQL Server configurada com mais de 64 endereços IP.

  • Você não pode usar MultiSubnetFailover=Yes com espelhamento de banco de dados. O driver retorna um erro quando a cadeia de conexão especifica Failover_Partner, e também quando o servidor indica que o banco de dados está espelhado. 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.

  • Use a Autenticação do SQL Server ou a Autenticação Kerberos com MultiSubnetFailover=Yes, sem afetar o comportamento da aplicação.

  • Aumente loginTimeout para levar em conta o tempo de failover e reduzir as tentativas de reconexão da aplicação. Para Banco de Dados SQL do Azure serverless com autopausa ativada, use pelo menos 60 segundos. Um banco de dados pausado automaticamente é retomado na primeira tentativa de conexão, e essa tentativa pode falhar com o erro 40613 enquanto o banco de dados recomeça, então a aplicação deve tentar novamente. Para mais informações, veja Pausa automática e retomada automática na camada de computação sem servidor do Banco de Dados SQL do Azure.

  • 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ário em um grupo de disponibilidade 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 usa ApplicationIntent=ReadWrite e o local da réplica secundária está configurado para acesso somente para leitura.

A conexão falha se uma réplica primária estiver configurada para rejeitar cargas de trabalho de somente leitura, e a cadeia de conexão contiver ApplicationIntent=ReadOnly.

Especificar a intenção do aplicativo

Você pode especificar a palavra-chave ApplicationIntent na sua cadeia de conexão. Os valores atribuíveis são ReadWrite (o padrão) ou ReadOnly.

Quando você define ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao se conectar. O servidor aplica a intenção no momento da conexão e durante uma instrução USE de banco de dados.

A palavra-chave ApplicationIntent não funciona com bancos de dados legados somente para leitura.

Destinos de ReadOnly

Quando uma conexão escolhe ReadOnly, ela é atribuída a qualquer uma das configurações especiais que podem existir para o banco de dados:

  • Sempre ligado. Um banco de dados pode permitir ou não cargas de trabalho de leitura no banco de dados do grupo de disponibilidade de destino. Essa opção é controlada usando a cláusula ALLOW_CONNECTIONS das instruções do Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.

  • Geo-replication

  • Expansão de leitura

Se nenhum desses destinos especiais estiver disponível, a leitura será feita do banco de dados normal.

A palavra-chave ApplicationIntent permite o roteamento somente para leitura.

Roteamento somente para leitura

O roteamento 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 leitura, todos os itens a seguir se aplicam:

  • Você deve se conectar a um ouvinte do grupo de disponibilidade Always On.

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

  • O administrador de banco de dados deve configurar o grupo de disponibilidade para habilitar o roteamento de somente leitura.

Várias conexões que usam roteamento somente leitura podem se conectar à mesma réplica somente leitura. Alterações na sincronização de banco de dados ou na configuração de roteamento do servidor podem resultar em conexões de cliente a réplicas diferentes de leitura apenas.

Você pode garantir que todas as solicitações somente leitura conectem-se à mesma réplica somente leitura, não transmitindo um ouvinte de grupo de disponibilidade à palavra-chave de cadeia de conexão Server. Em vez disso, especifique o nome da instância somente leitura.

O roteamento somente leitura pode levar mais tempo do que se conectar ao principal. Isso é porque o roteamento somente leitura se conecta primeiro à instância primária e, em seguida, procura a melhor instância secundária legível disponível. Devido a essas várias etapas, você deve aumentar seu tempo limite do login para no mínimo 30 segundos.

Sintaxe do ODBC

Duas palavras-chave da cadeia de conexão ODBC dão suporte a grupos de disponibilidade Always On:

  • ApplicationIntent

  • MultiSubnetFailover

Para obter mais informações sobre as palavras-chave da cadeia de conexão ODBC, consulte Using Connection String Keywords with SQL Server Native Client.

Os atributos de conexão equivalentes são:

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Para saber mais sobre as propriedades de conexão do ODBC, consulte SQLSetConnectAttr.

Um aplicativo ODBC que use os grupos de disponibilidade Always On pode usar uma dessas duas funções para fazer a conexão:

Função Description
Função SQLConnect SQLConnect dá suporte a ApplicationIntent e MultiSubnetFailover por meio de um DSN (nome de fonte de dados) ou de atributo de conexão.
função SQLDriverConnect SQLDriverConnect dá suporte aApplicationIntent e MultiSubnetFailover por meio de DSN, palavra-chave de cadeia de conexão ou atributo de conexão.

Conteúdo relacionado

  • Last updated on