Suporte a cliente nativo do SQL Server para alta disponibilidade e recuperação de desastre

Este tópico discute o suporte ao SQL Server Native Client (adicionado no SQL Server 2012) para Grupos de Disponibilidade AlwaysOn. Para obter mais informações sobre grupos de disponibilidade AlwaysOn, consulte Ouvintes do Grupo de Disponibilidade, Conectividade do Cliente e Failover de Aplicativo (SQL Server),Criação e Configuração de Grupos de Disponibilidade (SQL Server),Clustering de Failover e Grupos de Disponibilidade AlwaysOn (SQL Server) e Secundários Ativos: Réplicas Secundárias Legíveis (Grupos de Disponibilidade AlwaysOn).

Você pode especificar o ouvinte do grupo de disponibilidade de um determinado grupo de disponibilidade na cadeia de conexão. Se um aplicativo SQL Server Native Client estiver conectado a um banco de dados em um grupo de disponibilidade que faz 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 se conectando a um ouvinte de grupo de disponibilidade e se vários endereços IP estiverem associados a um nome de host, o SQL Server Native Client iterará sequencialmente por meio de 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 ouvinte de grupo de disponibilidade, o SQL Server Native Client tenta estabelecer conexões com todos os endereços IP em paralelo e, se uma tentativa de conexão for bem-sucedida, o driver descartará todas as tentativas de conexão pendentes.

Conectando-se ao MultiSubnetFailover

Sempre especifique MultiSubnetFailover=Yes quando for se conectar a um ouvinte de grupo de disponibilidade do SQL Server 2012 ou uma instância de cluster de failover do SQL Server 2012. MultiSubnetFailover permite failover mais rápido para todos os Grupos de Disponibilidade e instância de cluster de failover no SQL Server 2012 e reduzirá significativamente o tempo de failover para topologias AlwaysOn de várias sub-redes e única. Durante um failover de várias sub-redes, o cliente tentará conexões em paralelo. Durante um failover de sub-rede, o SQL Server Native Client repetirá agressivamente a conexão TCP.

A MultiSubnetFailover propriedade de conexão indica que o aplicativo está sendo implantado em um grupo de disponibilidade ou instância de cluster de failover e que o SQL Server Native Client 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=Yes é 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 Grupo de Disponibilidade AlwaysOn ou uma Instância de Cluster de Failover AlwaysOn e é aplicável a grupos de disponibilidade de várias sub-redes e instâncias de cluster de failover.

Para obter mais informações sobre palavras-chave de cadeia de conexão, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

Especificar MultiSubnetFailover=Yes ao se conectar a algo diferente de um ouvinte de grupo de disponibilidade ou instância de cluster de failover pode resultar em um impacto negativo no desempenho e não há suporte.

Use as diretrizes a seguir para conectar-se a um servidor em um grupo de disponibilidade ou Instância de Cluster de Failover:

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

• Você pode aumentar o valor de acomodar para o tempo de loginTimeout failover e reduzir as tentativas de repetição de conexão do aplicativo.

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

Se o roteamento somente leitura não estiver em vigor, a conexão com um local de réplica secundária em um grupo de disponibilidade falhará nas seguintes situações:

1. Se o local de réplica secundário não for configurado para aceitar conexões.

2. Se um aplicativo usar ApplicationIntent=ReadWrite (abordado abaixo) e o local da réplica secundária estiver configurado para acesso 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 ocorrerá se as palavras-chave e Failover_Partner conexão MultiSubnetFailover estiverem presentes na cadeia de conexão. Um erro também ocorrerá se MultiSubnetFailover for usado e o SQL Server retornar uma resposta de parceiro de failover indicando que ele faz parte de um par de espelhamento de banco de dados.

Se você atualizar um aplicativo do SQL Server Native Client que atualmente usa espelhamento de banco de dados para um cenário de várias sub-redes, remova a Failover_Partner propriedade de conexão e substitua-a pelo MultiSubnetFailover conjunto e Yes substitua o nome do servidor na cadeia de conexão por um ouvinte de grupo de disponibilidade. Se a cadeia de conexão usar Failover_Partner e MultiSubnetFailover=Yes, o driver gerará um erro. No entanto, se uma cadeia de conexão usar Failover_Partner e MultiSubnetFailover=No (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 grupo de disponibilidade e se MultiSubnetFailover=Yes for usado na cadeia de conexão que se conecta a um banco de dados primário em vez de a um ouvinte de grupo de disponibilidade.

Especificando a intenção do aplicativo

Quando ApplicationIntent=ReadOnlyo cliente solicita uma carga de trabalho de 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 ler cargas de trabalho 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 Server. 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.

ODBCODBC

Duas palavras-chave de cadeia de conexão ODBC foram adicionadas para dar suporte a Grupos de Disponibilidade AlwaysOn no SQL Server Native Client:

• ApplicationIntent

• MultiSubnetFailover

Para obter mais informações sobre palavras-chave da cadeia de conexão ODBC no SQL Server Native Client, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

As propriedades de conexão equivalentes são:

• SQL_COPT_SS_APPLICATION_INTENT

• SQL_COPT_SS_MULTISUBNET_FAILOVER

Para obter mais informações sobre as propriedades de conexão ODBC no SQL Server Native Client, consulte SQLSetConnectAttr.

A funcionalidade das palavras-chave e MultiSubnetFailover das ApplicationIntent palavras-chave será exposta no Administrador da Fonte de Dados ODBC para DSNs que usam o driver do SQL Server Native Client, começando no SQL Server 2012.

Um aplicativo ODBC do SQL Server Native Client pode usar uma das três funções para fazer a conexão:

OLE DB

O OLE DB no SQL Server Native Client não dá suporte à MultiSubnetFailover palavra-chave.

O OLE DB no SQL Server Native Client dará suporte à intenção do aplicativo. A intenção do aplicativo se comportará da mesma forma para aplicativos OLE DB que aplicativos ODBC (consulte acima).

Uma palavra-chave de cadeia de conexão OLE DB adicionada para dar suporte a Grupos de Disponibilidade AlwaysOn no SQL Server Native Client:

• Application Intent

Para obter mais informações sobre palavras-chave de cadeia de conexão no SQL Server Native Client, consulte Usando palavras-chave de cadeia de conexão com o SQL Server Native Client.

As propriedades de conexão equivalentes são:

• SSPROP_INIT_APPLICATIONINTENT

• DBPROP_INIT_PROVIDERSTRING

Um aplicativo OLE DB do SQL Server Native Client pode usar um dos métodos para especificar a intenção do aplicativo:

IDBInitialize::Initialize
IDBInitialize::Initialize usa o conjunto de propriedades configurado anteriormente para inicializar a fonte de dados e criar o objeto de fonte de dados. Especifique a intenção do aplicativo como uma propriedade de provedor ou como parte da cadeia de caracteres de propriedades estendidas.

IDataInitialize::GetDataSource
IDataInitialize::GetDataSource usa uma cadeia de conexão de entrada que pode conter a Application Intent palavra-chave.

IDBProperties::GetProperties
IDBProperties::GetProperties recupera o valor da propriedade que está definida atualmente na fonte de dados. Você pode recuperar o Application Intent valor por meio da propriedade DBPROP_INIT_PROVIDERSTRING e SSPROP_INIT_APPLICATIONINTENT propriedade.

IDBProperties::SetProperties
Para definir o valor da ApplicationIntent propriedade, chame IDBProperties::SetProperties passar a propriedade com o SSPROP_INIT_APPLICATIONINTENT valor "ReadWrite" ou "ReadOnly" ou DBPROP_INIT_PROVIDERSTRING a propriedade com o valor que contém "ApplicationIntent=ReadOnly" ou "ApplicationIntent=ReadWrite".

Você pode especificar a intenção do aplicativo no campo Propriedades de Intenção do Aplicativo da guia Todos na caixa de diálogo Propriedades do Link de Dados .

Quando conexões implícitas são estabelecidas, a conexão implícita usará a configuração de intenção do aplicativo da conexão pai. Da mesma forma, várias sessões criadas a partir da mesma fonte de dados herdarão a configuração de intenção de aplicativo da fonte de dados.

Consulte Também

Recursos do SQL Server Native Client
Usando palavras-chave da cadeia de conexão com o SQL Server Native Client