Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Este artículo trata sobre Microsoft SqlClient Proveedor de datos para soporte de SQL Server para alta disponibilidad y recuperación ante desastres, incluyendo los Grupos de Disponibilidad Siempre Activos. Para más información, consulte los grupos de disponibilidad Always On.
Ahora puedes especificar el oyente de un grupo de disponibilidad de alta disponibilidad y recuperación ante desastres (HADR) o de una instancia de clúster de conmutación por error (FCI) en la propiedad de conexión. Si una aplicación SqlClient se conecta a una base de datos Always On en la que se produce una conmutación por error, la conexión original se interrumpe y la aplicación debe abrir una nueva conexión para continuar funcionando después de la conmutación por error.
Si no se conecta a un oyente de grupo de disponibilidad o a una FCI, y si hay varias direcciones IP asociadas a un nombre de host, SqlClient recorre secuencialmente todas las direcciones IP asociadas a la entrada DNS. Este proceso puede ser laborioso si la primera dirección IP devuelta por el servidor DNS no está vinculada a ninguna tarjeta de interfaz de red (NIC). Cuando te conectas a un oyente AG o a una FCI, SqlClient intenta establecer conexiones a todas las direcciones IP en paralelo. Si un intento de conexión tiene éxito, el controlador descarta todos los intentos de conexión pendientes.
Nota
El aumento del tiempo de espera de la conexión y la implementación de la lógica de reintento de conexión aumentarán la probabilidad de que una aplicación se conecte a un grupo de disponibilidad. Además, dado que una conexión puede fallar debido a una conmutación por error, debería implementar lógica de reintento de conexión, reintentando una conexión fallida hasta que se restablezca.
Las siguientes propiedades de conexión se admiten en el proveedor de datos SqlClient de Microsoft para SQL Server:
ApplicationIntentMultiSubnetFailover
Puede modificar mediante programación estas palabras clave de cadena de conexión con:
Conectarse a MultiSubnetFailover
Siempre especifica MultiSubnetFailover=True cuándo te conectas a un punto final TCP de la familia Microsoft SQL. Esta configuración se aplica a los oyentes de grupos de disponibilidad, a las instancias de clúster de conmutación por error y a los puntos de conexión con varias direcciones IP, como Azure SQL Database, Azure SQL Managed Instance y la base de datos SQL en Microsoft Fabric.
Cuando el nombre del servidor en la cadena de conexión se resuelve en más de una dirección IP, MultiSubnetFailover=True hace que SqlClient abra conexiones a todas esas direcciones al mismo tiempo y utilice la primera que responda. Sin él, SqlClient prueba las direcciones una a una. Una dirección que no responde se detiene hasta que expira el tiempo de espera de conexión TCP del sistema operativo, que puede agotarse Connect Timeout antes de que SqlClient llegue a una dirección que responde. Tras una conmutación por error, la dirección que SqlClient intenta primero puede ser una que ya no da servicio a la base de datos, por lo que una conexión que se establecería correctamente con otra dirección falla en su lugar por agotamiento del tiempo de espera.
MultiSubnetFailover=True cambia la rapidez con la que el cliente encuentra la réplica que sirve a la base de datos. No cambia el tiempo que tarda el servidor en realizar la conmutación por error. Con esta configuración activada, SqlClient también reintenta las conexiones TCP con mayor rapidez que los intervalos predeterminados de retransmisión TCP del sistema operativo, lo que acelera la reconexión tanto para grupos de disponibilidad de una sola subred y de varias subredes como para instancias de clústeres de conmutación por error.
MultiSubnetFailover=True es seguro contra objetivos de una sola IP. Cuando DNS se resuelve a una sola dirección, SqlClient hace un único intento de conexión, así que la configuración no cuesta nada cuando no es necesaria.
Para obtener más información sobre las palabras clave de cadena de conexión de SqlClient, vea ConnectionString. Para obtener orientación sobre la configuración relacionada con la resolución transparente de direcciones IP de red (TNIR) en .NET Framework, y para solucionar problemas de conexiones lentas causadas por nombres DNS con varias direcciones IP, consulta Desactivación de la resolución transparente de direcciones IP de red y Retrasos prolongados en la conexión con tiempo de espera del protocolo de enlace previo al inicio de sesión.
Utiliza las siguientes pautas al configurar MultiSubnetFailover:
Establezca
MultiSubnetFailover=True.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.
No puedes usarla
MultiSubnetFailovercuando te conectas a una instancia con nombre.No puedes usarlo
MultiSubnetFailoveren un protocolo que no sea TCP.Conectarse a una instancia de SQL Server configurada con más de 64 direcciones IP provoca un fallo de conexión.
No puedes utilizar
MultiSubnetFailovercon la duplicación de bases de datos. Para obtener más información, consulte Actualización para utilizar clústeres con varias subredes desde la duplicación de bases de datos. El reflejo de bases de datos está obsoleto en todas las versiones compatibles de SQL Server. Use en su lugar los grupos de disponibilidad de Always On.El comportamiento de una aplicación que usa la propiedad de conexión
MultiSubnetFailoverno se ve afectado por el tipo de autenticación: de SQL Server, Kerberos o Windows.Aumente el valor de
Connect Timeoutpara tener en cuenta el tiempo de conmutación por error y reducir los reintentos de conexión de la aplicación.No se admiten las transacciones distribuidas.
Si no está activado el enrutamiento de solo lectura, no se puede conectar a una ubicación de réplica secundaria en las siguientes situaciones:
Si la ubicación de réplica secundaria no está configurada para aceptar conexiones.
Si una aplicación utiliza
ApplicationIntent=ReadWrite(como se explica a continuación) y la ubicación de la réplica secundaria está configurada para acceso de solo lectura.
SqlDependency no se admite en las réplicas secundarias de solo lectura.
Una conexión producirá un error si una réplica principal está configurada para rechazar las cargas de trabajo de solo lectura y la cadena de conexión contiene ApplicationIntent=ReadOnly.
Actualización para usar clústeres de varias subredes a partir de la creación de reflejo de la base de datos
Se producirá un error de conexión (ArgumentException) si las palabras clave de conexión MultiSubnetFailover y Failover Partner están presentes en la cadena de conexión, o si se usa MultiSubnetFailover=True y un protocolo distinto de TCP. También se produce un error (SqlException) si se usa MultiSubnetFailover y SQL Server devuelve una respuesta del asociado de conmutación por error que indica que forma parte de un par de creación de reflejo de la base de datos.
Si actualiza una aplicación SqlClient que usa actualmente la creación de reflejo de la base de datos para un escenario de varias subredes, debe quitar la propiedad de conexión Failover Partner y reemplazarla por MultiSubnetFailover establecida en True y reemplazar el nombre de servidor en la cadena de conexión por una escucha de grupo de disponibilidad. Si una cadena de conexión utiliza Failover Partner y MultiSubnetFailover=True, el controlador generará un error. Sin embargo, si una cadena de conexión utiliza Failover Partner y MultiSubnetFailover=False (o ApplicationIntent=ReadWrite), la aplicación utilizará la creación de reflejo de la base de datos.
El controlador devuelve un error si se utiliza la duplicación de bases de datos en la réplica principal del grupo de disponibilidad y si se establece MultiSubnetFailover=True en la cadena de conexión que se conecta a una réplica principal en lugar de a un oyente del grupo de disponibilidad.
Especificación de intención de aplicaciones
Cuando configuras ApplicationIntent=ReadOnly, el cliente solicita una carga de trabajo de lectura cuando te conectas a una base de datos habilitada para Always On. El servidor aplica la intención en el momento de establecer la conexión y durante una instrucción de base de datos USE, pero solo en una base de datos habilitada para Always On.
La palabra clave ApplicationIntent no funciona con bases de datos de solo lectura heredadas.
Una base de datos puede permitir o denegar la lectura de las cargas de trabajo en la base de datos de destino Always On. (Esto se hace con la cláusula ALLOW_CONNECTIONS de las instrucciones Transact-SQL de PRIMARY_ROLE y SECONDARY_ROLE).
La palabra clave ApplicationIntent se utiliza para habilitar el enrutamiento de solo lectura.
Enrutamiento de solo lectura
El enrutamiento de solo lectura es una característica que puede garantizar la disponibilidad de una réplica de solo lectura de una base de datos. Para habilitar el enrutamiento de solo lectura:
Debe conectarse siempre a un agente de escucha de grupo de disponibilidad Always On.
La palabra clave de la cadena de conexión
ApplicationIntentdebe establecerse enReadOnly.El administrador de bases de datos debe configurar el grupo de disponibilidad para habilitar el enrutamiento de solo lectura.
Es posible que varias conexiones con 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 los cambios en la configuración de enrutamiento del servidor pueden producir conexiones de cliente para réplicas de solo lectura diferentes. 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 a la palabra clave de cadena de conexión Data Source. En su lugar, especifique el nombre de la instancia de solo lectura.
El enrutamiento de solo lectura puede tardar más en conectarse al servidor principal porque el enrutamiento de solo lectura se conecta primero al servidor principal y luego busca el mejor secundario legible disponible. Por ello, debe aumentar el tiempo de espera de inicio de sesión.