En este tema se describe la compatibilidad de Controlador Microsoft JDBC para SQL Server para la alta disponibilidad y la recuperación ante desastres: Grupos de disponibilidad AlwaysOn. Para obtener más información sobre Grupos de disponibilidad AlwaysOn, vea los Libros en pantalla de SQL Server 2012.
A partir de la versión 4.0 de Controlador Microsoft JDBC para SQL Server, puede especificar el agente de escucha de un grupo de disponibilidad (alta disponibilidad, recuperación ante desastres) en la propiedad de conexión. Si una aplicación Controlador Microsoft JDBC para SQL Server está conectada a una base de datos AlwaysOn que conmuta por error, se interrumpirá la conexión original y la aplicación deberá abrir una conexión nueva para seguir trabajando después de la conmutación por error.
Si no está conectado a un agente de escucha de grupo de disponibilidad y hay varias direcciones IP asociadas a un servidor, el Controlador Microsoft JDBC para SQL Server intentará conectarse a la primera dirección IP. Si el Controlador Microsoft JDBC para SQL Server no puede establecer una conexión con la primera dirección IP, se producirá un error en la conexión. El Controlador Microsoft JDBC para SQL Server no intentará conectarse a ninguna dirección IP más asociada al servidor. Cuando se conecta a un agente de escucha de grupo de disponibilidad, el Controlador Microsoft JDBC para SQL Server intenta establecer conexiones con todas las direcciones IP en paralelo y, si un intento de conexión se realiza correctamente, el controlador descartará los demás intentos de conexión pendientes.
Si se aumenta el tiempo de espera de conexión y se implementar lógica de reintento de conexión, aumentará la probabilidad de que una aplicación se conecte a un grupo de disponibilidad. Además, como se puede producir un error en una conexión debido a la conmutación por error de un grupo de disponibilidad, se debe implementar lógica de reintento de conexión para reintentar una conexión errónea hasta que vuelva a conectarse.
Se han agregado al Controlador Microsoft JDBC 4.0 para SQL Server las siguientes propiedades de conexión:
multiSubnetFailover
applicationIntent
Conectar con MultiSubnetFailover
Especifique siempre multiSubnetFailover=true cuando se conecte al agente de escucha de un grupo de disponibilidad de SQL Server 2012 o una instancia de clúster de conmutación por error de SQL Server 2012. multiSubnetFailover permite una conmutación por error más rápida para todos los grupos de disponibilidad y todas las instancias de clúster de conmutación por error en SQL Server 2012, y reducirá considerablemente el tiempo de conmutación por error en las topologías AlwaysOn de una y de múltiples subredes. Durante una conmutación por error de múltiples subredes, el cliente intentará establecer conexiones en paralelo. Durante una conmutación por error de subred, el Controlador Microsoft JDBC para SQL Server reintentará agresivamente la conexión TCP.
La propiedad de conexión multiSubnetFailover indica que la aplicación se está implementando en un grupo de disponibilidad o en una instancia de clúster de conmutación por error y que el Controlador Microsoft JDBC para SQL Server intentará conectar con la base de datos en la instancia principal de SQL Server intentando conectarse a todas las direcciones IP. Cuando se especifica MultiSubnetFailover=true para una conexión, el cliente reintenta la conexión TCP más deprisa que los intervalos de retransmisión TCP predeterminados del sistema operativo. Esto permite una reconexión más rápida después de la conmutación por error de un grupo de disponibilidad o una instancia de clúster de conmutación por error AlwaysOn, tanto de una como de múltiples subredes.
Para obtener más información acerca de las palabras clave de la cadena de conexión en el Controlador Microsoft JDBC para SQL Server, vea Establecer las propiedades de conexión.
La especificación de multiSubnetFailover=true al conectar con algo distinto de un agente de escucha de grupo de disponibilidad o una instancia de clúster de conmutación por error puede afectar negativamente al rendimiento y no se admite.
Si el administrador de seguridad no está instalado, la máquina virtual Java almacenará en memoria caché las direcciones IP virtuales (VIP) durante un período finito de tiempo, definido de manera predeterminada por la implementación de JDK y por las propiedades networkaddress.cache.ttl y networkaddress.cache.negative.ttl de Java. Si el administrador de seguridad de JDK está instalado, la máquina virtual Java almacenará en memoria caché las VIP y no actualizará la caché de forma predeterminada. Debe establecer el valor de "período de vida" (networkaddress.cache.ttl) en un día para la memoria caché de la máquina virtual Java. Si no cambia el valor predeterminado a un día (aproximadamente), el valor anterior no se purgará de la memoria caché de la máquina virtual Java cuando se agregue o se actualice una VIP. Para obtener más información sobre networkaddress.cache.ttl y networkaddress.cache.negative.ttl, vea http://download.oracle.com/javase/6/docs/technotes/guides/net/properties.html.
Use las directrices siguientes para conectarse a un servidor de un grupo de disponibilidad o una instancia de clúster de conmutación por error:
El controlador generará un error si la propiedad de conexión instanceName se usa en la misma cadena de conexión que la propiedad de conexión multiSubnetFailover. Esto refleja el hecho de que SQL Browser no se usa en un grupo de disponibilidad. Sin embargo, si también se especifica la propiedad de conexión portNumber, el controlador omitirá instanceName y usará portNumber.
Use la propiedad de conexión multiSubnetFailover cuando se conecte a una única subred o a varias subredes, ya que mejorará el rendimiento en ambos casos.
Para conectarse a un grupo de disponibilidad, especifique el agente de escucha del grupo de disponibilidad como el servidor en la cadena de conexión. Por ejemplo, jdbc:sqlserver://VNN1.
La conexión con una instancia de SQL Server configurada con más de 64 direcciones IP producirá un error de conexión.
El comportamiento de una aplicación que usa la propiedad de conexión multiSubnetFailover no se ve afectado por el tipo de autenticación: autenticación de SQL Server, autenticación Kerberos o autenticación de Windows.
Incremente el valor de loginTimeout para dar tiempo a la conmutación por error y reducir los reintentos de conexión de la aplicación.
No se admiten transacciones distribuidas.
Si el enrutamiento de solo lectura no está vigente, se producirá un error al conectarse a una ubicación de réplica secundaria en un grupo de disponibilidad en las situaciones siguientes:
Si la ubicación de réplica secundaria no está configurada para aceptar conexiones.
Si una aplicación usa applicationIntent=ReadWrite (se describe más adelante) y la ubicación de réplica secundaria está configurada para acceso de solo lectura.
Se producirá un error en la conexión si una réplica principal está configurada para rechazar cargas de trabajo de solo lectura y la cadena de conexión contiene ApplicationIntent=ReadOnly.
Actualizar para usar clústeres de múltiples subredes desde la creación de reflejo de la base de datos
Si actualiza a un escenario de múltiples subredes una aplicación del Controlador Microsoft JDBC para SQL Server que emplea actualmente creación de reflejo de la base de datos, debe quitar la propiedad de conexión failoverPartner y reemplazarla con multiSubnetFailover establecida en true, y reemplazar el nombre del servidor en la cadena de conexión con un agente de escucha de grupo de disponibilidad. Si una cadena de conexión emplea failoverPartner y multiSubnetFailover=true, el controlador generará un error. Sin embargo, si una cadena de conexión usa failoverPartner y multiSubnetFailover=false (o ApplicationIntent=ReadWrite), la aplicación usará la creación de reflejo de la base de datos.
El controlador devolverá un error si la creación de reflejo de la base de datos se usa en la base de datos principal del grupo de disponibilidad y si se usa multiSubnetFailover=true en la cadena de conexión para conectarse a una base de datos principal en lugar de a un agente de escucha de grupo de disponibilidad.
Especificar la intención de la aplicación
Cuando applicationIntent=ReadOnly, el cliente solicita una carga de trabajo de solo lectura al conectarse a una base de datos habilitada para AlwaysOn. El servidor exigirá la intención en el momento de la conexión y durante una instrucción USE DATABASE, pero solo para una base de datos habilitada para AlwaysOn.
La palabra clave applicationIntent no funciona con bases de datos heredadas de solo lectura.
Una base de datos puede permitir o impedir cargas de trabajo de lectura en la base de datos AlwaysOn de destino. (Para ello se emplea la cláusula ALLOW_CONNECTIONS de las instrucciones PRIMARY_ROLE y SECONDARY_ROLE de Transact-SQL.)
La palabra clave applicationIntent se usa para habilitar el enrutamiento de solo lectura.
Enrutamiento de solo lectura
El enrutamiento de solo lectura es una característica que puede asegurar la disponibilidad de una réplica de solo lectura de una base de datos. Para habilitar el enrutamiento de solo lectura:
Debe conectarse a un agente de escucha de grupo de disponibilidad AlwaysOn.
La palabra clave applicationIntent de la cadena de conexión se debe establecer en ReadOnly.
El administrador de base de datos debe configurar el grupo de disponibilidad para que permita el enrutamiento de solo lectura.
Es posible que varias conexiones que usan enrutamiento de solo lectura no se conecten todas a la misma réplica de solo lectura. Los cambios en la sincronización de la base de datos o en la configuración de enrutamiento del servidor pueden hacer que los clientes se conecten a distintas réplicas de solo lectura. Para asegurarse de que todas las solicitudes de solo lectura se conectan a la misma réplica de solo lectura, no pase un agente de escucha de grupo de disponibilidad o una dirección IP virtual a la palabra clave serverName de la cadena de conexión. En su lugar, especifique el nombre de la instancia de solo lectura.
El enrutamiento de solo lectura puede tardar más tiempo que la conexión a la réplica principal, ya que primero se conecta a la réplica principal y después busca la mejor réplica secundaria legible disponible. Este es el motivo por el que debe aumentar el tiempo de espera de inicio de sesión.
Nuevos métodos que admiten multiSubnetFailover y applicationIntent
Los métodos siguientes ofrecen acceso mediante programación a las palabras clave multiSubnetFailover y applicationIntent de la cadena de conexión:
Los métodos getMultiSubnetFailover, setMultiSubnetFailover, getApplicationIntent y setApplicationIntent también se han agregado a Clase SQLServerDataSource, Clase SQLServerConnectionPoolDataSource y Clase SQLServerXADataSource.
Validación de certificados SSL
Un grupo de disponibilidad consta de varios servidores físicos. Controlador Microsoft JDBC 4.0 para SQL Server agregó compatibilidad con Subject Alternate Name en los certificados SSL, por lo que es posible asociar varios hosts al mismo certificado. Para obtener más información sobre SSL, vea Descripción de la compatibilidad con SSL.