Partilhar via

Suporte de drivers JDBC para Alta Disponibilidade, recuperação após desastres

Baixar driver JDBC

Este artigo discute o suporte do Driver Microsoft JDBC para SQL Server em relação à alta disponibilidade e à recuperação de desastres, especificamente no que diz respeito aos grupos de disponibilidade Always On. Para mais informações sobre grupos de disponibilidade Always On, consulte SQL Server 2012 (11.x) Books Online.

A partir da versão 4.0 do Microsoft JDBC Driver for SQL Server, pode especificar o ouvinte do grupo de disponibilidade de um grupo de disponibilidade (AG) (alta disponibilidade, recuperação de desastres) na propriedade de ligação. Se um driver Microsoft JDBC para uma aplicação SQL Server estiver ligado a uma base de dados Always On que faz failover, a ligação original é interrompida e a aplicação tem de abrir uma nova ligação para continuar o trabalho após o failover. As seguintes propriedades de ligação foram adicionadas no Microsoft JDBC Driver 4.0 para SQL Server:

  • multiSubnetFailover

  • Intenção de aplicação

Especifique multiSubnetFailover=true ao ligar-se ao ouvinte do grupo de disponibilidade de um grupo de disponibilidade ou a uma Instância de Cluster de Failover.

Observação

multiSubnetFailover é falso por defeito. Use applicationIntent para declarar o tipo de carga de trabalho da aplicação. Para mais detalhes, consulte as secções abaixo.

A partir da versão 6.0 do Microsoft JDBC Driver para SQL Server, é adicionada uma nova propriedade de ligação, transparentNetworkIPResolution (TNIR), para uma ligação transparente a grupos de disponibilidade Always On ou a um servidor que tenha múltiplos endereços IP associados. Quando transparentNetworkIPResolution é verdadeiro, o driver tenta ligar-se ao primeiro endereço IP disponível. Se a primeira tentativa falhar, o driver tenta ligar-se a todos os endereços IP em paralelo até o timeout expirar, descartando quaisquer tentativas de ligação pendentes quando uma delas tem sucesso.

Observação:

  • a resolução de IP de rede transparente é verdadeira por defeito
  • transparentNetworkIPResolution é ignorado se multiSubnetFailover estiver ativado
  • A resolução de transparentNetworkIP é desconsiderada se for utilizado o espelhamento de bases de dados
  • A solução do transparentNetworkIP é ignorada se existirem mais de 64 endereços IP
  • Quando a solução transparentNetworkIPR é verdadeira, a primeira tentativa de ligação utiliza um valor de timeout de 500 ms. O resto das tentativas de ligação segue a mesma lógica da funcionalidade multiSubnetFailover.

Observação

Se estiver a utilizar o Microsoft JDBC Driver 4.2 (ou inferior) para SQL Server e se multiSubnetFailover for falso, o Microsoft JDBC Driver para SQL Server tenta conectar-se ao primeiro endereço IP. Se o driver Microsoft JDBC para SQL Server não conseguir estabelecer uma ligação com o primeiro endereço IP, a ligação falha. O Driver Microsoft JDBC para SQL Server não tentará ligar-se a qualquer endereço IP subsequente associado ao servidor.

Observação

Aumentar o tempo de espera da ligação e implementar lógica de retentativa de ligação aumentará a probabilidade de uma aplicação se ligar a um grupo de disponibilidade. Além disso, como uma ligação pode falhar devido a um failover de grupo de disponibilidade, deve implementar lógica de retentativa de ligação, tentando novamente uma ligação falhada até que esta se reconecte.

Ligação com o multiSubnetFailover

Especifique sempre multiSubnetFailover=true ao ligar-se ao listener do 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 um failover mais rápido para todos os Availability Groups e instâncias de clusters de failover no SQL Server 2012 (11.x) e reduz significativamente o tempo de failover para topologias Always On de sub-redes únicas e múltiplas. Durante um failover multi-sub-rede, o cliente tentará ligações em paralelo. Durante um failover de sub-rede, o driver Microsoft JDBC para SQL Server tentará repetidamente a ligação TCP.

A propriedade de ligação multiSubnetFailover indica que a aplicação está a ser implementada num grupo de disponibilidade ou numa Instância de Cluster de Failover e que o driver Microsoft JDBC para SQL Server tentará ligar-se à base de dados na instância principal do SQL Server, tentando conectar-se a todos os endereços IP. Quando MultiSubnetFailover=true é especificado para uma ligação, 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. Este comportamento possibilita uma reconexão mais rápida após o failover de um Always On Availability Group ou de uma Always On Failover Cluster Instance, e aplica-se tanto a Grupos de Disponibilidade de sub-rede única como a múltiplas sub-redes e Instâncias de Cluster de Failover.

Para mais informações sobre palavras-chave da cadeia de ligação no Microsoft JDBC Driver for SQL Server, consulte Definir as Propriedades de Ligação.

Especificar multiSubnetFailover=true ao conectar-se a algo que não seja um listener de grupo de disponibilidade ou uma Instância de Cluster de Failover pode ter um impacto negativo no desempenho e não é suportado.

Se o gestor de segurança não estiver instalado, a Máquina Virtual Java armazena em cache endereços IP virtuais (VIPs) por um período finito de tempo, por defeito, definido pela sua implementação JDK e pelas propriedades Java networkaddress.cache.ttl e networkaddress.cache.negative.ttl. Se o gestor de segurança JDK estiver instalado, a Máquina Virtual Java irá armazenar em cache os VIPs e não atualizará a cache por padrão. Deves definir o "time-to-live" (networkaddress.cache.ttl) para um dia para a cache da Máquina Virtual Java. Se não mudares o valor predefinido para um dia (ou assim), o valor antigo não será eliminado da cache da Máquina Virtual Java quando um VIP for adicionado ou atualizado. Para mais informações sobre networkaddress.cache.ttl e networkaddress.cache.negative.ttl, consulte Propriedades de Rede.

Use as seguintes diretrizes para se ligar a um servidor num grupo de disponibilidade ou numa Instância de Cluster de Failover:

  • O driver gerará um erro se a propriedade de ligação instanceName for utilizada na mesma cadeia de ligação que a propriedade multiSubnetFailover. Este erro reflete o facto de o SQL Browser não ser utilizado num grupo de disponibilidade. No entanto, se a propriedade de ligação portNumber também for especificada, o driver irá ignorar instanceName e usar portNumber.

  • Use a propriedade de ligação multiSubnetFailover ao ligar-se a uma única subrede ou multissubredes, melhorando o desempenho de ambas.

  • Para se ligar a um grupo de disponibilidade, especifique o ouvinte do grupo de disponibilidade do grupo de disponibilidade como o servidor na sua cadeia de ligação. Por exemplo, jdbc:sqlserver://VNN1.

  • Ligar a uma instância SQL Server configurada com mais de 64 endereços IP causará uma falha de ligação.

  • O comportamento de uma aplicação que utiliza a propriedade de ligação multiSubnetFailover não é afetado consoante o tipo de autenticação: Autenticação SQL Server, Autenticação Kerberos ou Autenticação Windows.

  • Aumente o valor do loginTimeout para acomodar o tempo de failover e reduzir as tentativas de ligação à aplicação.

Se o roteamento de leitura não estiver em vigor, a conexão a uma localização secundária da réplica num grupo de disponibilidade falhará 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 utilizar applicationIntent=ReadWrite (conforme discutido abaixo) e a localização da réplica secundária estiver configurada para acesso só de leitura.

Uma ligação falhará 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.

Atualização para utilizar clusters multi-sub-redes a partir do espelhamento de bases de dados

Se atualizar um driver Microsoft JDBC para uma aplicação SQL Server que atualmente usa espelhamento de base de dados para um cenário multi-sub-rede, deve remover a propriedade de ligação failoverPartner e substituí-la por multiSubnetFailover definida como true, e deve também substituir o nome do servidor na string de ligação por um listener de grupo de disponibilidade. Se uma cadeia de ligação usar failoverPartner e multiSubnetFailover=true, o driver gerará um erro. No entanto, se uma cadeia de ligação usar failoverPartner e multiSubnetFailover=false (ou ApplicationIntent=ReadWrite), a aplicação usará espelhamento da base de dados.

O driver devolverá um erro se o espelhamento da base de dados for utilizado na base de dados primária dentro do AG, e se multiSubnetFailover=true for utilizado na string de conexão que se liga a uma base de dados primária em vez de a um listener de grupo de disponibilidade.

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 faz cumprir a intenção no momento da ligação e durante uma USE instrução da base de dados.

A ApplicationIntent palavra-chave não funciona com bases de dados legadas de apenas 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 usando a ALLOW_CONNECTIONS cláusula das PRIMARY_ROLE instruções e SECONDARY_ROLE Transact-SQL.

  • Geo-replication

  • Escalamento horizontal de leituras

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

A ApplicationIntent palavra-chave permite o encaminhamento apenas de leitura.

Encaminhamento de apenas leitura

O encaminhamento apenas de leitura é uma funcionalidade que pode garantir a disponibilidade de uma réplica somente de leitura de uma base 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 ligação deve ser definida para ReadOnly.

  • O administrador da base de dados deve configurar o grupo de disponibilidade para permitir o encaminhamento apenas de leitura.

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

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

O encaminhamento só de leitura pode demorar mais do que ligar 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 estes múltiplos passos, deve aumentar o seu login tempo para pelo menos 30 segundos.

Agrupamento de conexões

Ao utilizar o Microsoft JDBC Driver para SQL Server em combinação com uma biblioteca de pooling de ligações, deve considerar os seguintes pontos:

  • Se tiver o encaminhamento apenas de leitura configurado e um conjunto de servidores apenas de leitura sobre os quais pretende distribuir a carga, o agrupamento de ligações reduzirá as oportunidades de novas ligações se espalharem pelos servidores de destino.
  • Para evitar uma carga maior num único servidor de um pool, escolha opções de pool que incentivem uma distribuição equilibrada das ligações ao longo do pool.
  • Certifica-te de que o teu pool de ligações está configurado com uma vida útil da ligação. Caso uma réplica em modo só de leitura não esteja disponível quando se faz uma ligação desse tipo, a configuração deve garantir que a ligação seja eventualmente fechada e restabelecida assim que uma réplica de leitura estiver disponível novamente.

Novos métodos que suportam multiSubnetFailover e applicationIntent

Os seguintes métodos fornecem-lhe acesso programático às palavras-chave da string de ligação multiSubnetFailover, applicationIntent e transparentNetworkIPResolution:

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

Validação de certificados TLS/SSL

Um grupo de disponibilidade consiste em múltiplos servidores físicos. O Microsoft JDBC Driver 4.0 para SQL Server adicionou suporte para Subject Alternate Name em certificados TLS/SSL, para que múltiplos hosts possam ser associados ao mesmo certificado. Para mais informações sobre TLS, veja Compreender o suporte à encriptação.

Consulte também

Conectando-se ao SQL Server com o driver JDBC
Definindo as propriedades da conexão

  • Last updated on