Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
p-PT: Este tópico discute o suporte do Microsoft SqlClient Data Provider for SQL Server para alta disponibilidade e recuperação de desastres -- Grupos de Disponibilidade Always On. O recurso Grupos de Disponibilidade Always On foi adicionado ao SQL Server 2012. Para obter mais informações sobre grupos de disponibilidade Always On, consulte os Manuais Online do SQL Server.
Agora você pode especificar o ouvinte do grupo de disponibilidade de um grupo de disponibilidade (AG) (alta disponibilidade, recuperação de desastres) ou da Instância de Cluster de Failover do SQL Server 2012 na propriedade de conexão. Se um aplicativo SqlClient estiver conectado a um banco de dados Always On que faça 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 ou a uma Instância de Cluster de Failover do SQL Server 2012 e se vários endereços IP estiverem associados a um nome de host, o SqlClient iterará sequencialmente através de todos os endereços IP associados à entrada DNS. Isso pode ser demorado se o primeiro endereço IP retornado pelo servidor DNS não estiver vinculado a nenhuma placa de interface de rede (NIC). Ao estabelecer uma conexão com um ouvinte de grupo de disponibilidade ou uma instância de cluster de failover do SQL Server 2012, o SqlClient tenta conectar-se a todos os endereços IP simultaneamente. Se uma destas tentativas de conexão for bem-sucedida, o driver descartará quaisquer outras tentativas de conexão que ainda estejam pendentes.
Observação
Aumentar o tempo limite de conexão e implementar a lógica de repetição de conexão aumentará 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 a lógica de repetição de conexão, tentando novamente uma conexão com falha até que ela se reconecte.
As seguintes propriedades de conexão são suportadas no Microsoft SqlClient Data Provider for SQL Server:
ApplicationIntentMultiSubnetFailover
Você pode modificar programaticamente essas palavras-chave de cadeia de conexão com:
Ligação com MultiSubnetFailover
Sempre especifique MultiSubnetFailover=True ao conectar-se a um listener do grupo de disponibilidade do SQL Server 2012 ou a uma instância de cluster de failover do SQL Server 2012.
MultiSubnetFailover permite failover mais rápido para todos os Grupos de Disponibilidade e/ou Instância de Cluster de Failover no SQL Server 2012 e reduzirá significativamente o tempo de failover para topologias Always On de sub-rede única e múltipla. Durante um failover de várias sub-redes, o cliente tentará conexões em paralelo. Durante um failover de sub-rede, repetirá agressivamente a conexão TCP.
A propriedade MultiSubnetFailover de conexão indica que a aplicação está a ser implementada num grupo de disponibilidade ou na instância de cluster de failover do SQL Server 2012 e que o SqlClient tentará conectar-se ao banco de dados na instância primária do SQL Server, tentando conectar-se a todos os endereços IP. Quando MultiSubnetFailover=True é especificado para uma conexão, o cliente tenta novamente a 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 Always On ou de uma Instância de Cluster de Failover Always On e é aplicável a Grupos de Disponibilidade de sub-rede única e múltipla e Instâncias de Cluster de Failover.
Para obter mais informações sobre palavras-chave de cadeia de conexão em SqlClient, consulte ConnectionString.
Especificar MultiSubnetFailover=True ao estabelecer ligação com algo diferente de um listener de grupo de disponibilidade ou Instância de Cluster de Failover do SQL Server 2012 pode resultar em um impacto negativo no desempenho e não é suportado.
Use as diretrizes a seguir para se conectar a um servidor em um grupo de disponibilidade ou Instância de Cluster de Failover do SQL Server 2012:
Use a propriedade de ligação
MultiSubnetFailoverao ligar-se a uma só sub-rede ou a várias sub-redes; isso melhorará o desempenho de ambas.Para se conectar a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade como servidor na sua cadeia de conexão.
A conexão com 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
MultiSubnetFailoverpropriedade de conexão 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 do
Connect Timeoutpara acomodar o tempo de failover e reduza 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ário falhará nas seguintes situações:
Se o local da réplica secundária não estiver configurado para aceitar conexões.
Se um aplicativo usar
ApplicationIntent=ReadWrite(discutido abaixo) e o local da réplica secundária estiver configurado para acesso somente leitura.
SqlDependency não é suportado em réplicas secundárias apenas de leitura.
Uma ligação falhará se uma réplica primária estiver configurada para rejeitar cargas de trabalho de leitura só e a string de conexão contiver ApplicationIntent=ReadOnly.
Atualização para utilização de clusters de várias sub-redes em substituição ao espelhamento de base de dados
Um erro de conexão (ArgumentException) ocorrerá se as MultiSubnetFailover palavras-chave e Failover Partner conexão estiverem presentes na cadeia de conexão ou se MultiSubnetFailover=True e um protocolo diferente de TCP for usado. Um erro (SqlException) também ocorrerá se MultiSubnetFailover for usado e o SQL Server retornar uma resposta de parceiro de failover indicando que faz parte de um par de espelhamento de banco de dados.
Se atualizar uma aplicação SqlClient que atualmente utiliza espelhamento de banco de dados para 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 na string de conexão por um listener de grupo de disponibilidade. Se uma 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á 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 utilizado na cadeia de conexão que se conecta a um banco de dados primário, em vez de a um ouvinte do grupo de disponibilidade.
Especificando a intenção do aplicativo
Quando ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao conectar-se a um banco de dados com Always On habilitado. O servidor imporá a intenção no momento da conexão e durante uma instrução de banco de dados USE, mas somente para um banco de dados habilitado para Always On.
A ApplicationIntent palavra-chave não funciona com bancos de dados legados e somente leitura.
Um banco de dados pode permitir ou recusar cargas de trabalho de leitura no banco de dados Always On de destino. (Isto é feito com a cláusula ALLOW_CONNECTIONS das declarações PRIMARY_ROLE e da declaração SECONDARY_ROLE Transact-SQL.)
A ApplicationIntent palavra-chave é usada para ativar o encaminhamento só de leitura.
Roteio de somente leitura
O roteamento em modo somente leitura é uma funcionalidade que pode garantir a disponibilidade de uma réplica em modo somente leitura de um banco de dados. Para ativar o roteio só de leitura:
Você deve se conectar a um ouvinte do grupo de disponibilidade do Grupo de Disponibilidade AlwaysOn.
A
ApplicationIntentpalavra-chave da cadeia de conexão deve ser definida comoReadOnly.O Grupo de Disponibilidade deve ser configurado pelo administrador do banco de dados para habilitar o roteamento somente leitura.
É possível que várias conexões usando roteamento somente leitura não se conectem todas à mesma réplica somente 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. Para garantir que todas as solicitações somente leitura se conectem à mesma réplica somente leitura, não passe um ouvinte do grupo de disponibilidade para a Data Source palavra-chave da cadeia de conexão. Em vez disso, especifique o nome da instância somente leitura.
O roteamento somente leitura pode levar mais tempo do que a conexão com o primário porque o roteamento somente leitura primeiro se conecta ao primário e, em seguida, procura o melhor secundário legível disponível. Por isso, você deve aumentar o tempo limite de login.