Suporte a JDBC Driver para alta disponibilidade e recuperação de desastre

Baixar o JDBC Driver

Este artigo discute o suporte do Microsoft JDBC Driver para SQL Server para alta disponibilidade e recuperação de desastre: grupos de disponibilidade Always On. Para obter mais informações sobre os grupos de disponibilidade Always On, confira os Manuais Online do SQL Server 2012 (11.x).

Com a versão 4.0 do Microsoft JDBC Driver para SQL Server, é possível especificar o ouvinte do grupo de disponibilidade de um AG (grupo de disponibilidade) (alta disponibilidade, recuperação de desastre) na propriedade de conexão. Se um aplicativo Microsoft JDBC Driver para SQL Server estiver conectado a um banco de dados Always On que efetua failover, a conexão original será interrompida e o aplicativo deverá abrir uma nova conexão para continuar o trabalho após o failover. As seguintes propriedades de conexão foram adicionadas ao Microsoft JDBC Driver 4.0 para SQL Server:

  • multiSubnetFailover

  • applicationIntent

Especifique multiSubnetFailover=true ao se conectar ao ouvinte do grupo de disponibilidade de um grupo de disponibilidade ou uma instância de cluster de failover.

Observação

multiSubnetFailover é falso por padrão. Use applicationIntent para declarar o tipo de carga de trabalho do aplicativo. Para obter mais detalhes, confira a seção abaixo.

A partir da versão 6.0 do Microsoft JDBC Driver for SQL Server, uma nova propriedade de conexão TNIR (transparentNetworkIPResolution) foi adicionada à conexão transparente com grupos de disponibilidade Always On ou a um servidor que tem vários endereços IP associados. Quando transparentNetworkIPResolution estiver definido como true, o driver tenta se conectar ao primeiro endereço IP disponível. Se a primeira tentativa falhar, o driver tentará se conectar a todos os endereços IP em paralelo até que o tempo limite expire, descartando todas as tentativas de conexão pendentes quando uma delas for bem-sucedida.

Observação:

  • transparentNetworkIPResolution é verdadeiro por padrão
  • transparentNetworkIPResolution será ignorada se multiSubnetFailover for true
  • transparentNetworkIPResolution será ignorada se o espelhamento de banco de dados for usado
  • transparentNetworkIPResolution será ignorada se houver mais de 64 endereços IP
  • Quando transparentNetworkIPResolution for true, a primeira tentativa de conexão usará 500 ms como o tempo limite. O restante das tentativas de conexão seguirá a mesma lógica do recurso multiSubnetFailover.

Observação

Se você estiver usando o Microsoft JDBC Driver 4.2 (ou anterior) para SQL Server e se multiSubnetFailover estiver definido como false, o Microsoft JDBC Driver para SQL Server tentará se conectar ao primeiro endereço IP. Se o Microsoft JDBC Driver para SQL Server não puder estabelecer uma conexão com o primeiro endereço IP, a conexão apresentará falha. O Microsoft JDBC Driver para SQL Server não tentará se conectar a nenhum endereço IP subsequente associado ao servidor.

Observação

O aumento do tempo limite de conexão e a implementação de lógica de repetição de conexão aumentarão 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 em um grupo de disponibilidade, você deve implementar lógica de repetição de tentativas de conexão, tentando novamente uma conexão com falha até que ela seja restabelecida.

Conectando-se a multiSubnetFailover

Sempre especifique multiSubnetFailover=True ao se conectar ao ouvinte de um grupo de disponibilidade do SQL Server 2012 (11.x) ou a uma instância de cluster de failover do SQL Server 2012 (11.x). multiSubnetFailover permite o failover mais rápido para todos os Grupos de Disponibilidade e instâncias de cluster de failover no SQL Server 2012 (11.x) e reduzirá significativamente o tempo de failover para topologias Always On de uma ou várias sub-redes. Durante um failover de várias sub-redes, o cliente tentará conexões em paralelo. Durante um failover de sub-rede, o Microsoft JDBC Driver para SQL Server tentará restabelecer a conexão TCP repetidamente.

A propriedade de conexão multiSubnetFailover indica que o aplicativo está sendo implantado em um grupo de disponibilidade ou instância de cluster de failover e que o Microsoft JDBC Driver para SQL Server tentará se conectar ao banco de dados na instância primária do SQL Server tentando se conectar a todos os endereços IP do grupo de disponibilidade. Quando MultiSubnetFailover=true é especificado para uma conexão, o cliente repete as tentativas de conexão TCP mais rapidamente do que os intervalos de retransmissão TCP padrão do sistema operacional. Esse comportamento permite uma reconexão mais rápida depois do failover de um Grupo de Disponibilidade Always On ou uma Instância de Cluster de Failover Always On e se aplica a Grupos de Disponibilidade e Instâncias de Cluster de Failover com uma ou várias sub-redes.

Para obter mais informações sobre palavras-chave de cadeia de conexão no Microsoft JDBC Driver para SQL Server, confira Configuração das propriedades de conexão.

A especificação de multiSubnetFailover=true durante a conexão a algo que não seja um ouvinte de grupo de disponibilidade ou uma Instância de Cluster de Failover pode resultar em um impacto de desempenho negativo e isso não é compatível.

Se o gerenciador de segurança não for instalado, a Máquina Virtual Java armazenará VIPs (endereços IP virtuais) em cache por um período determinado, por padrão, definido pela implementação JDK e as propriedades Java networkaddress.cache.ttl e networkaddress.cache.negative.ttl. Se o gerenciador de segurança JDK for instalado, a Máquina Virtual Java armazenará VIPs em cache e não atualizará o cache, por padrão. Você deve definir o "time-to-live" (networkaddress.cache.ttl) como um dia para o cache da Máquina Virtual Java. Se você não alterar o valor padrão para um dia (ou valor parecido), o valor antigo não será limpo no cache da Máquina Virtual Java quando um VIP for adicionado ou atualizado. Para obter mais informações sobre networkaddress.cache.ttl e networkaddress.cache.negative.ttl, consulte Propriedades de Rede.

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

  • O driver gerará um erro se a propriedade de conexão instanceName for usada na mesma cadeia de conexão da propriedade de conexão multiSubnetFailover. Esse erro acontece porque o SQL Browser não é usado em um grupo de disponibilidade. No entanto, se a propriedade de conexão portNumber também for especificada, o driver ignorará instanceName e usará portNumber.

  • Use a propriedade de conexão multiSubnetFailover quando estiver se conectando a uma ou várias sub-redes, isso melhorará o desempenho em ambos os casos.

  • Para conectar-se a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade como o servidor em sua cadeia de conexão. Por exemplo, jdbc:sqlserver://VNN1.

  • 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 SQL Server, Autenticação Kerberos ou Autenticação do Windows.

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

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

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

  • Se um aplicativo usar applicationIntent=ReadWrite (discutido abaixo) e o local de réplica secundária estiver configurado para acesso somente leitura.

A conexão falhará se uma réplica primária estiver configurada para rejeitar cargas de trabalho somente de 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

Se você atualizar um aplicativo do Microsoft JDBC Driver para SQL Server que atualmente usa espelhamento de banco de dados para um cenário com várias sub-redes, deverá remover a propriedade de conexão failoverPartner, substituí-la por multiSubnetFailover definida 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 usa failoverPartner e multiSubnetFailover=true, o driver gerará um erro. No entanto, se uma cadeia de conexão usar failoverPartner e multiSubnetFailover=false (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 AG e se multiSubnetFailover=true for usado na cadeia de conexão que se conecta a um banco de dados primário, em vez de ao ouvinte do grupo de disponibilidade.

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 impõe a intenção no momento da conexão e durante uma instrução do banco de dados USE.

A palavra-chave ApplicationIntent não funciona com bancos de dados legados somente de 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 bloquear cargas de trabalho de leitura no banco de dados de destino do grupo de disponibilidade. Essa opção é controlada usando a cláusula ALLOW_CONNECTIONS das instruções do Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.

  • Replicação geográfica

  • Expansão de leitura

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

A palavra-chave ApplicationIntent permite o roteamento de somente 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 do 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 alterações na configuração de roteamento de servidor podem resultar em conexões de cliente com réplicas somente leitura diferentes.

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 de somente leitura.

O roteamento somente para leitura pode levar mais tempo do que a conexão com a instância primária. 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.

Pool de conexões

Ao usar o Microsoft JDBC Driver para o SQL Server em conjunto com uma biblioteca de pool de conexões, considere os seguintes pontos:

  • Se você tiver o roteamento de somente leitura configurado e um pool de servidores de somente leitura entre os quais deseja distribuir a carga, o pool de conexões reduzirá o número de oportunidades para que novas conexões sejam distribuídas entre os servidores de destino.
  • Para evitar uma carga maior em qualquer servidor individual em um pool, escolha opções de pool que incentivem uma distribuição uniforme das conexões por todo o pool.
  • Verifique se o pool de conexões está configurado com um tempo de vida de conexão. Caso uma réplica de somente leitura não esteja disponível quando for estabelecida uma conexão de somente leitura, a configuração deverá garantir que essa conexão acabe sendo fechada e restabelecida com uma réplica de somente leitura quando uma voltar a ficar disponível.

Novos métodos com suporte para multiSubnetFailover e applicationIntent

Os seguintes métodos fornecem acesso programático às palavras-chave de cadeia de conexão multiSubnetFailover, applicationIntent e transparentNetworkIPResolution:

Os métodos getMultiSubnetFailover, setMultiSubnetFailover, getApplicationIntent, setApplicationIntent, getTransparentNetworkIPResolution e setTransparentNetworkIPResolution também são adicionados às classes SQLServerDataSource, SQLServerConnectionPoolDataSource e SQLServerXADataSource.

Validação do certificado TLS/SSL

Um grupo de disponibilidade consiste em vários servidores físicos. O Microsoft JDBC Driver 4.0 para SQL Server adicionou suporte ao Nome Alternativo da Entidade aos certificados TLS/SSL para que vários hosts possam ser associados ao mesmo certificado. Para obter mais informações sobre o TLS, confira Noções básicas do suporte à criptografia.

Conteúdo relacionado

  • Last updated on