Alta disponibilidade e recuperação após desastres

Baixar driver ODBC

O Microsoft ODBC Driver for SQL Server suporta grupos de disponibilidade Always On. Para mais informações sobre os grupos de disponibilidade Always On, veja:

• Ligar a um serviço de escuta do grupo de disponibilidade AlwaysOn

• Referência para a criação e configuração de grupos de disponibilidade Always On

• Agrupamento de ativação pós-falha e grupos de disponibilidade Always On (SQL Server)

• Transferir carga de trabalho só de leitura para a réplica secundária de um grupo de disponibilidade Always On

Pode especificar o ouvinte do grupo de disponibilidade de um determinado grupo de disponibilidade na cadeia de conexão. Se uma aplicação ODBC se ligar a uma base de dados num grupo de disponibilidade que faz failover, a ligação original é interrompida. A aplicação deve abrir uma nova ligação para continuar a trabalhar após o failover.

Sem MultiSubnetFailover=Yes, o mecanismo legado de fallback multi-IP do controlador pode ser lento quando o primeiro endereço IP resolvido não está acessível. Para mais informações sobre o comportamento de recurso do Windows, consulte Usar resolução de IP de rede transparente com o controlador ODBC.

Quando estabelece ligação com um listener do grupo de disponibilidade utilizando MultiSubnetFailover=Yes, o controlador tenta estabelecer ligações, em paralelo, a todos os endereços IP resolvidos. Se uma tentativa de ligação for bem-sucedida, o driver descarta quaisquer tentativas de ligação pendentes.

Liga-te ao MultiSubnetFailover

Define MultiSubnetFailover=Yes quando o destino é Base de Dados SQL do Azure, Azure SQL Managed Instance, base 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, fazendo com que o controlador tente estabelecer ligações TCP para todos os endereços IP resolvidos em paralelo e utilize a primeira ligação que for bem-sucedida.

Esta propriedade de ligação também reduz 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, o driver reatenta agressivamente à ligação TCP.

A propriedade de ligação MultiSubnetFailover indica que a aplicação está a ser implantada numa topologia em que o hostname de destino pode corresponder a mais do que um ponto final. O driver tenta ligar-se à base de dados na instância principal do SQL Server tentando ligar-se a todos os endereços IP.

Quando se liga usando MultiSubnetFailover=Yes, o cliente tenta novamente as tentativas de ligação TCP mais rapidamente do que os intervalos padrão de retransmissão TCP do sistema operativo. MultiSubnetFailover=Yes permite reconexões mais rápidas após falhas de um grupo de disponibilidade Always On ou de uma instância de cluster de failover Always On. MultiSubnetFailover=Yes Aplica-se tanto a grupos de disponibilidade de uma única subrede como a de múltiplas subredes e a instâncias de clusters de failover.

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

Recommendations

Quando estabelece ligação a um destino de alta disponibilidade ou com múltiplos pontos finais (Base de Dados SQL do Azure, Azure SQL Managed Instance, base de dados SQL no Microsoft Fabric, um escutador de grupo de disponibilidade ou uma instância de cluster de ativação pós-falha):

• Especifique MultiSubnetFailover=Yes. É a configuração recomendada para estes alvos, e é seguro deixá-la ligada quando o destino resolve para um único endereço IP, porque o driver faz então uma única tentativa de ligação.

• Especifique o ouvinte do grupo de disponibilidade como o servidor na sua cadeia de ligação.

• Não podes usar MultiSubnetFailover=Yes por cima de um protocolo que não seja TCP.

• Não podes ligar-te a uma instância SQL Server configurada com mais de 64 endereços IP.

• Não se pode usar MultiSubnetFailover=Yes com espelhamento de base de dados. O controlador gera um erro quando a cadeia de ligação especifica Failover_Partner, e também quando o servidor indica que a base de dados está espelhada. O espelhamento de bases de dados está obsoleto em todas as versões suportadas do SQL Server. Em vez disso, use os grupos de disponibilidade Always On.

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

• Aumente loginTimeout para ter em conta o tempo de failover e reduzir as tentativas de repetição de ligação da aplicação. Para Base de Dados SQL do Azure serverless com autopausa ativada, use pelo menos 60 segundos. Uma base de dados em pausa automática recomeça na primeira tentativa de ligação, e essa tentativa pode falhar com o erro 40613 enquanto a base de dados recomeça, pelo que a aplicação tem de tentar novamente. Para mais informações, consulte Pausa automática e retoma automática na camada de computação sem servidor do Base de Dados SQL do Azure.

• Transações distribuídas não são suportadas.

Se o encaminhamento apenas de leitura não estiver em vigor, a ligação a uma localização secundária de réplica num grupo de disponibilidade falha nas seguintes situações:

• Se a localização da réplica secundária não estiver configurada para aceitar ligações.

• Se uma aplicação usar ApplicationIntent=ReadWrite e o local da réplica secundária estiver configurado para acesso apenas de leitura.

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

Especifique a intenção da aplicação

Podes especificar a palavra-chave ApplicationIntent na tua cadeia de ligação. Os valores atribuíveis são ReadWrite (o padrão) ou ReadOnly.

Quando defines ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao ligar. O servidor impõe a intenção aquando da ligação e durante uma USE instrução da base de dados.

A palavra-chave ApplicationIntent não funciona com bases de dados antigas apenas de leitura.

Alvos do ReadOnly

Quando uma ligação escolhe ReadOnly, a ligação é atribuída a qualquer uma das seguintes configurações especiais que possam existir para a base de dados:

• Sempre ligado. Uma base de dados pode permitir ou não a leitura de cargas de trabalho na base de dados do grupo de disponibilidade alvo. Esta escolha é controlada através da utilização da cláusula ALLOW_CONNECTIONS das instruções Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.

• Geo-replication

• Expansão horizontal de leitura

Se nenhum desses alvos especiais estiver disponível, a base de dados regular é consultada.

ApplicationIntent palavra-chave permite encaminhamento só de leitura.

Roteio de somente leitura

O roteamento somente leitura é um recurso que pode garantir a disponibilidade de uma réplica somente leitura de um banco de dados. Para permitir o encaminhamento apenas de leitura, aplicam-se todas as seguintes condições:

• Deve ligar-se a um ouvinte do grupo de disponibilidade Always On.

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

• O administrador da base de dados deve configurar o grupo de disponibilidade para ativar o encaminhamento só de leitura.

Várias ligações que usam roteamento apenas de leitura podem não se ligar todas à mesma réplica de apenas leitura. Modificações na sincronização da base de dados ou alterações na configuração de roteamento do servidor podem resultar em ligações dos clientes a diferentes réplicas de leitura apenas.

Pode garantir que todos os pedidos só de leitura se liguem à mesma réplica só de leitura não passando um escutador de grupo de disponibilidade para a palavra-chave Server da cadeia de ligação. Em vez disso, especifique o nome da instância somente leitura.

O encaminhamento só de leitura pode demorar mais do que estabelecer ligação ao primário. Isto acontece porque o encaminhamento apenas de leitura liga-se primeiro ao primário e depois procura o melhor secundário legível disponível. Devido a estas várias etapas, deve aumentar o seu login tempo limite para, pelo menos, 30 segundos.

Sintaxe ODBC

Duas palavras-chave da cadeia de ligação ODBC suportam grupos de disponibilidade Always On.

• ApplicationIntent

• MultiSubnetFailover

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

Os atributos de ligação equivalentes são:

• SQL_COPT_SS_APPLICATION_INTENT

• SQL_COPT_SS_MULTISUBNET_FAILOVER

Para mais informações sobre atributos de ligação ODBC, consulte SQLSetConnectAttr.

Uma aplicação ODBC que utiliza grupos de disponibilidade Always On pode usar uma de duas funções para estabelecer a ligação:

Conteúdo relacionado

• Palavras-chave e atributos de DSN e de cadeias de ligação
• Use resolução IP de rede transparente com o driver ODBC
• Ligação a partir de Linux ou macOS
• Orientações de programação