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

Defina multiSubnetFailover=true quando o destino for Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, banco de dados SQL no Microsoft Fabric, um listener de 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 informações, consulte as secções seguintes.

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á um valor de tempo limite de 500 milissegundos. O restante das tentativas de conexão segue 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 quando o destino for o Banco de Dados SQL do Azure, o Instância Gerenciada de SQL do Azure, um banco de dados SQL no Microsoft Fabric, um ouvinte de um grupo de disponibilidade do SQL Server 2012 (11.x) ou uma instância de cluster de failover do SQL Server 2012 (11.x).

Quando o nome do servidor na sua cadeia de conexão é resolvido para mais de um endereço IP, multiSubnetFailover=true faz com que o driver Microsoft JDBC para SQL Server abra conexões para todos esses endereços ao mesmo tempo e use o primeiro que responder. Sem ele, o driver volta ao Transparent Network IP Resolution (TNIR), que está ativado por padrão. O TNIR tenta um único endereço com um timeout de 500 milissegundos e abre conexões para todos os endereços resolvidos apenas na próxima tentativa. Se você também definir transparentNetworkIPResolution=false, o driver tenta um único endereço com o loginTimeout completo e nunca tenta os outros, então uma conexão que teria sucesso contra outro endereço falha. Depois que um failover move o banco de dados para uma réplica em um endereço diferente, multiSubnetFailover=true permite alcançar o novo endereço já na primeira tentativa.

multiSubnetFailover=true altera a rapidez com que o cliente encontra a réplica que atende ao banco de dados. Isso não muda o tempo que o servidor leva para fazer failover.

multiSubnetFailover=true é seguro em alvos de IP único. Quando o DNS resolve para um único endereço, o driver faz uma única tentativa de conexão e não inicia nenhuma thread de conexão paralela, então a configuração não custa nada quando não é necessária.

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.

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:

  • Defina a propriedade de conexão multiSubnetFailover como true.

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

  • Você pode usar a propriedade de conexão instanceName em conjunto com multiSubnetFailover. O driver consulta o SQL Browser em cada endereço resolvido para encontrar a porta da instância. Se você também especificar portNumber, o driver usa portNumber e não consulta o SQL Browser.

  • A conexão a uma instância do SQL Server configurada com mais de 64 endereços IP falha. O driver trata como uma configuração não suportada e não tenta a conexão novamente.

  • Você não pode usar multiSubnetFailover com espelhamento de banco de dados. O driver retorna um erro quando a cadeia de conexão especifica failoverPartner, e também quando o servidor retorna um failover partner. 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.

  • 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 do loginTimeout para acomodar o tempo de failover e reduzir as tentativas de reconexão da aplicação. Para Banco de Dados SQL do Azure serverless com pausa automática habilitada, loginTimeout também precisa ser grande o suficiente para comportar as tentativas de reconexão do driver. Para mais informações, consulte Conectar-se a um banco de dados serverless pausado automaticamente.

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 (conforme descrito mais adiante neste artigo) e o local da réplica secundária estiver configurado somente para 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 retorna um erro se você usar espelhamento de banco de dados na réplica primária no AG, e se você usar multiSubnetFailover=true na cadeia de conexão que se conecta a uma réplica primária em vez de a um ouvinte de 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