Supporto del driver JDBC per il ripristino di emergenza a disponibilità elevata

Scaricare il driver JDBC

Questo articolo illustra il supporto di Microsoft JDBC Driver per SQL Server per il ripristino di emergenza e la disponibilità elevata tramite Gruppi di disponibilità Always On. Per altre informazioni sui gruppi di disponibilità Always On, vedere la documentazione online di SQL Server 2012 (11.x).

A partire dalla versione 4.0 di Microsoft JDBC Driver per SQL Server, è possibile specificare nella proprietà di connessione il listener di un gruppo di disponibilità (a disponibilità elevata e ripristino di emergenza) (AG). Se un'applicazione Microsoft JDBC Driver per SQL Server è connessa a un database Always On che esegue il failover, la connessione originale viene interrotta e l'applicazione deve aprire una nuova connessione per proseguire con l'esecuzione dopo il failover. Le proprietà di connessione seguenti sono state aggiunte in Microsoft JDBC Driver 4.0 per SQL Server:

  • multiSubnetFailover

  • applicationIntent

Imposta multiSubnetFailover=true quando il target è database SQL di Azure, Istanza gestita di SQL di Azure, un database SQL in Microsoft Fabric, un listener di gruppo di disponibilità o un'istanza del cluster di failover.

Nota

multiSubnetFailover è false per impostazione predefinita. Usare applicationIntent per dichiarare il tipo di carico di lavoro dell'applicazione. Per altre informazioni, vedere le sezioni seguenti.

A partire dalla versione 6.0 di Microsoft JDBC Driver per SQL Server viene aggiunta una nuova proprietà di connessione transparentNetworkIPResolution (TNIR), per la connessione trasparente ai gruppi di disponibilità Always On o a un server con più indirizzi IP associati. Quando la proprietà transparentNetworkIPResolution è true, il driver tenta di connettersi al primo indirizzo IP disponibile. Se il primo tentativo non riesce, il driver tenta di connettersi a tutti gli indirizzi IP in parallelo fino alla scadenza del timeout, annullando tutti i tentativi di connessione in sospeso quando uno di essi ha esito positivo.

Nota:

  • transparentNetworkIPResolution è vero per impostazione predefinita
  • transparentNetworkIPResolution viene ignorata se multiSubnetFailover è vero
  • transparentNetworkIPResolution viene ignorata se viene usato il mirroring del database
  • transparentNetworkIPResolution viene ignorata se sono presenti più di 64 indirizzi IP
  • Quando la soluzione transparentNetworkIP è vera, il primo tentativo di connessione utilizza un valore di timeout di 500 millisecondi. Il resto dei tentativi di connessione segue la stessa logica della funzione multiSubnetFailover.

Nota

Se si usa Microsoft JDBC Driver 4.2 (o versione precedente) per SQL Server e se multiSubnetFailover è false, Microsoft JDBC Driver per SQL Server cerca di connettersi al primo indirizzo IP. Se Microsoft JDBC Driver per SQL Server non riesce a stabilire una connessione con il primo indirizzo IP, la connessione ha esito negativo. Microsoft JDBC Driver per SQL Server non cercherà di connettersi ad altri indirizzi IP successivi associati al server.

Nota

L'aumento del timeout di connessione e l'implementazione della logica di riesecuzione per le connessioni aumentano le probabilità che un'applicazione si connetta a un gruppo di disponibilità. Inoltre, poiché una connessione può non riuscire a causa del failover di un gruppo di disponibilità, è consigliabile implementare una logica di ritentativo della connessione, ritentando una connessione non riuscita finché non viene ristabilita.

Connessione con multiSubnetFailover

Specifica sempre multiSubnetFailover=true quando la destinazione è database SQL di Azure, Istanza gestita di SQL di Azure, un database SQL in Microsoft Fabric, un listener del gruppo di disponibilità di SQL Server 2012 (11.x) o un'istanza del cluster di failover di SQL Server 2012 (11.x).

Quando il nome del server nella tua stringa di connessione si risolve in più di un indirizzo IP, multiSubnetFailover=true fa sì che il driver Microsoft JDBC per SQL Server apra le connessioni a tutti quegli indirizzi contemporaneamente e usi il primo che risponde. Senza essa, il driver torna alla Transparent Network IP Resolution (TNIR), che è abilitata di default. TNIR prova un singolo indirizzo con un timeout di 500 millisecondi e apre le connessioni a tutti gli indirizzi risolti solo al tentativo successivo. Se imposti anche transparentNetworkIPResolution=false, il driver tenta di connettersi a un solo indirizzo per l'intera durata di loginTimeout e non tenta mai gli altri, quindi una connessione che andrebbe a buon fine con un altro indirizzo invece fallisce. Dopo un failover sposta il database su una replica a un indirizzo diverso, multiSubnetFailover=true raggiunge il nuovo indirizzo al primo tentativo.

multiSubnetFailover=true modifica la rapidità con cui il client trova la replica che serve il database. Non cambia quanto tempo impiega il server a fare il failover.

multiSubnetFailover=true è sicuro su destinazioni con un solo indirizzo IP. Quando il DNS si risolve su un unico indirizzo, il driver tenta una singola connessione e non avvia alcun thread di connessione parallelo, quindi l'impostazione non costa nulla quando non è necessaria.

Per altre informazioni sulle parole chiave delle stringhe di connessione in Microsoft JDBC Driver per SQL Server, vedere Impostazione delle proprietà di connessione.

Se lo strumento di gestione della sicurezza non è installato, Java Virtual Machine memorizza nella cache gli indirizzi IP virtuali (VIP) per un periodo di tempo limitato definito, per impostazione predefinita, dall'implementazione di JDK e dalle proprietà Java networkaddress.cache.ttl e networkaddress.cache.negative.ttl. Se è installato il security manager del JDK, la Java Virtual Machine memorizzerà nella cache i VIP e, per impostazione predefinita, non aggiornerà la cache. È consigliabile impostare "time-to-live" (networkaddress.cache.ttl) su un giorno per la cache di Java Virtual Machine. Se non si modifica il valore predefinito impostandolo su un giorno (o un valore simile), il vecchio valore non verrà rimosso dalla cache della Java Virtual Machine (JVM) quando viene aggiunto o aggiornato un VIP. Per altre informazioni su networkaddress.cache.ttl e networkaddress.cache.negative.ttl, vedere Proprietà di rete.

Utilizzare le linee guida seguenti per connettersi a un server in un gruppo di disponibilità o nell'istanza del cluster di failover:

  • Imposta la proprietà di connessione multiSubnetFailover su true.

  • Per connettersi a un gruppo di disponibilità, specificare, come server, il listener del gruppo di disponibilità nella stringa di connessione. Ad esempio, jdbc:sqlserver://VNN1.

  • Puoi usare la proprietà di connessione InstanceName insieme a multiSubnetFailover. Il driver interroga SQL Browser a ogni indirizzo risolto per trovare la porta dell'istanza. Se specifichi anche portNumber, il driver usa portNumber e non interroga SQL Browser.

  • La connessione a un'istanza SQL Server configurata con più di 64 indirizzi IP fallisce. Il driver lo considera una configurazione non supportata e non riprova la connessione.

  • Non puoi usare multiSubnetFailover con il mirroring del database. Il driver restituisce un errore quando la stringa di connessione specifica failoverPartner, e anche quando il server restituisce un partner di failover. Il mirroring del database è obsoleto in tutte le versioni supportate di SQL Server. Usare invece Gruppi di disponibilità Always On.

  • Il comportamento di un'applicazione che usa la proprietà di connessione multiSubnetFailover non è influenzato dal tipo di autenticazione, che può essere autenticazione di SQL Server, autenticazione Kerberos o autenticazione di Windows.

  • Aumentare il valore di loginTimeout per gestire i tempi di failover e ridurre i tentativi di riconnessione dell'applicazione. Per database SQL di Azure serverless con auto-pausa attivata, loginTimeout deve essere anche abbastanza grande da contenere i tentativi di connessione del driver. Per maggiori informazioni, consulta Connettersi a un database serverless con sospensione automatica.

Se il routing di sola lettura non è attivo, non è possibile stabilire una connessione a un percorso di replica secondaria in un gruppo di disponibilità nelle situazioni seguenti:

  • Se la località della replica secondaria non è configurata per accettare connessioni.

  • Se un'applicazione utilizza applicationIntent=ReadWrite (descritto più avanti in questo articolo) e la posizione della replica secondaria è configurata per l'accesso di sola lettura.

Una connessione non riesce se una replica primaria è configurata per rifiutare i carichi di lavoro in sola lettura e la stringa di connessione contiene ApplicationIntent=ReadOnly.

Aggiornamento per l'uso di cluster su più subnet dal mirroring del database

Se si aggiorna un'applicazione Microsoft JDBC Driver per SQL Server che usa il mirroring del database in uno scenario su più subnet, è necessario rimuovere la proprietà di connessione failoverPartner e sostituirla con la proprietà multiSubnetFailover impostata su true, nonché sostituire il nome del server nella stringa di connessione con un listener del gruppo di disponibilità. Se in una stringa di connessione vengono usati failoverPartner e multiSubnetFailover=true il driver genererà un errore. Se tuttavia in una stringa di connessione vengono usati failoverPartner e multiSubnetFailover=false (o ApplicationIntent=ReadWrite), l'applicazione userà il mirroring del database.

Il driver restituisce un errore se si utilizza il mirroring del database sulla replica primaria nell'AG e se si usa multiSubnetFailover=true nella stringa di connessione che si collega a una replica primaria invece che al listener del gruppo di disponibilità.

Specificare la finalità dell'applicazione

È possibile specificare la parola chiave ApplicationIntent nella stringa di connessione. I valori assegnabili sono ReadWrite (impostazione predefinita) e ReadOnly.

Quando si imposta il valore ApplicationIntent=ReadOnly, il client richiede un carico di lavoro di lettura durante la connessione. Il server applica la finalità al momento della connessione e durante un'istruzione di database USE.

La parola chiave ApplicationIntent non funziona con i database legacy di sola lettura.

Destinazioni di ReadOnly

Quando una connessione sceglie ReadOnly, la connessione viene assegnata a una delle configurazioni speciali seguenti che potrebbero essere disponibili per il database:

  • Sempre attivo. Un database può consentire o impedire carichi di lavoro di lettura nel database del gruppo di disponibilità di destinazione. Questa scelta viene controllata usando la clausola ALLOW_CONNECTIONS delle istruzioni Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.

  • Replica geografica

  • Read scale-out (Scalabilità in lettura)

Se nessuno di questi target speciali è disponibile, si legge il database standard.

La parola chiave ApplicationIntent è utilizzata per abilitare il routing di sola lettura.

Routing di sola lettura

Il routing di sola lettura è una funzionalità che può garantire la disponibilità di una replica di sola lettura di un database. Per abilitare il routing di sola lettura, si applicano tutte le condizioni seguenti:

  • È necessario connettersi a un listener del gruppo di disponibilità Always On.

  • La parola chiave della stringa di connessione ApplicationIntent deve essere impostata su ReadOnly.

  • L'amministratore del database deve configurare il gruppo di disponibilità in modo da abilitare il routing di sola lettura.

Più connessioni che usano il routing di sola lettura potrebbero non connettersi tutte alla stessa replica di sola lettura. Le modifiche nella sincronizzazione del database o nella configurazione di routing del server possono comportare connessioni client a repliche di sola lettura diverse.

Puoi garantire che tutte le richieste di sola lettura si connettano alla stessa replica di sola lettura non passando un listener del gruppo di disponibilità alla parola chiave della stringa di connessione Server. Specificare invece il nome dell'istanza di sola lettura.

L'instradamento di sola lettura potrebbe richiedere più tempo del collegamento al primario. Ciò dipende dal fatto che il routing di sola lettura si connette prima alla replica primaria e quindi cerca la migliore replica secondaria leggibile disponibile. A causa di questi passaggi aggiuntivi, è consigliabile aumentare il timeout di login ad almeno 30 secondi.

Pool di connessioni

Quando si usa Microsoft JDBC Driver per SQL Server in combinazione con la libreria di un pool di connessioni, è necessario considerare quanto segue:

  • Se è stato configurato il routing di sola lettura e un pool di server di sola lettura su cui si vuole distribuire il carico, il pool di connessioni ridurrà il numero di opportunità per la distribuzione di nuove connessioni tra i server di destinazione.
  • Per evitare un carico più elevato su un singolo server in un pool, scegliere le opzioni per il pool che assicurano una distribuzione uniforme delle connessioni nel pool.
  • Assicurati che il pool di connessioni sia configurato con una durata della connessione. Nel caso in cui una replica di sola lettura non sia disponibile quando viene effettuata una connessione di sola lettura, la configurazione deve garantire che la connessione venga chiusa e ristabilita in una replica di sola lettura quando ne diventa nuovamente disponibile una.

Nuovi metodi che supportano multiSubnetFailover e applicationIntent

I metodi seguenti consentono di accedere a livello di codice alle parole chiave della stringa di connessione multiSubnetFailover, applicationIntent e transparentNetworkIPResolution:

Vengono aggiunti anche i metodi getMultiSubnetFailover, setMultiSubnetFailover, getApplicationIntent, setApplicationIntent, getTransparentNetworkIPResolution e setTransparentNetworkIPResolution alle classi SQLServerDataSource, SQLServerConnectionPoolDataSource e SQLServerXADataSource.

Convalida del certificato TLS/SSL

Un gruppo di disponibilità è costituito da più server fisici. In Microsoft JDBC Driver 4.0 per SQL Server stato aggiunto il supporto per il nome alternativo soggetto nei certificati TLS/SSL, in modo che più host possano essere associati allo stesso certificato. Per altre informazioni su TLS, vedere Informazioni sul supporto della crittografia.

Contenuti correlati

  • Ultimo aggiornamento: