Compartir a través de

Compatibilidad de SQL Server Native Client con alta disponibilidad, recuperación ante desastres

En este tema se describe la compatibilidad con SQL Server Native Client (agregada en SQL Server 2012) para grupos de disponibilidad AlwaysOn. Para obtener más información sobre los grupos de disponibilidad AlwaysOn, vea Agentes de escucha de grupos de disponibilidad, conectividad de cliente y conmutación por error de aplicaciones (SQL Server),Creación y configuración de grupos de disponibilidad (SQL Server), clústeres de conmutación por error y grupos de disponibilidad AlwaysOn (SQL Server) y Secundarias activas: réplicas secundarias legibles (grupos de disponibilidad AlwaysOn).

Puede especificar el agente de escucha del grupo de disponibilidad de un grupo de disponibilidad determinado en la cadena de conexión. Si una aplicación de SQL Server Native Client está conectada a una base de datos de un grupo de disponibilidad que conmuta por error, se interrumpe la conexión original 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 agente de escucha de grupo de disponibilidad y si hay varias direcciones IP asociadas a un nombre de host, SQL Server Native Client itera secuencialmente a través de todas las direcciones IP asociadas a la entrada DNS. Esto puede llevar mucho tiempo si la primera dirección IP que devuelve el servidor DNS no está enlazada a una tarjeta (NIC) de interfaz de red. Al conectarse a un agente de escucha de grupo de disponibilidad, SQL Server Native Client intenta establecer conexiones a todas las direcciones IP en paralelo y, si un intento de conexión se realiza correctamente, el controlador descartará 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 producir un error debido a la conmutación por error de un grupo de disponibilidad, es aconsejable implementar la lógica de reintento de conexión y hacer que una conexión que no se ha podido establecer se reintente hasta que vuelva a conectarse.

Conectarse a MultiSubnetFailover

Especifique siempre MultiSubnetFailover=Yes al conectarse a un agente de escucha de grupo de disponibilidad de SQL Server 2012 o a 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 la instancia de clúster de conmutación por error en SQL Server 2012 y reducirá significativamente el tiempo de conmutación por error para topologías AlwaysOn de una y varias subredes. En un clúster de conmutación por error de varias subredes, el cliente intentará conexiones en paralelo. Durante una conmutación por error de subred, SQL Server Native Client reintentará agresivamente la conexión TCP.

La MultiSubnetFailover propiedad de conexión 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 SQL Server Native Client intentará conectarse a la base de datos en la instancia principal de SQL Server intentando conectarse a todas las direcciones IP. Cuando se especifica MultiSubnetFailover=Yes 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 AlwaysOn o de una instancia de clúster de conmutación por error AlwaysOn, y se aplica a los grupos de disponibilidad de una y varias subredes y a las instancias de clúster de conmutación por error.

Para obtener más información sobre las palabras clave de cadena de conexión, vea Usar palabras clave de cadena de conexión con SQL Server Native Client.

Especificar MultiSubnetFailover=Yes al conectarse a algo distinto de un agente de escucha de grupo de disponibilidad o una instancia de clúster de conmutación por error puede dar lugar a un impacto negativo en el rendimiento y no se admite.

Utilice las siguientes instrucciones para conectarse a un servidor en un grupo de disponibilidad o una instancia de clúster de conmutación por error:

  • Utilice la propiedad de conexión MultiSubnetFailover al conectarse a una sola subred o a varias subredes. Así mejorará el rendimiento en ambas situaciones.

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

  • La conexión a una instancia de SQL Server configurada con más de 64 direcciones IP producirá un error en la 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: de SQL Server, Kerberos o Windows.

  • Puede aumentar el valor de para adaptarse al tiempo de loginTimeout conmutación por error y reducir los reintentos de conexión de la aplicación.

  • No se admiten las transacciones distribuidas.

Si el enrutamiento de solo lectura no está en vigor, la conexión a una ubicación de réplica secundaria en un grupo de disponibilidad producirá un error en las situaciones siguientes:

  1. Si la ubicación de réplica secundaria no está configurada para aceptar conexiones.

  2. Si una aplicación utiliza ApplicationIntent=ReadWrite (se explica a continuación) y la ubicación de réplica secundaria está configurada para el acceso 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.

Actualizar para utilizar 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 si las MultiSubnetFailover palabras clave y Failover_Partner están presentes en la cadena de conexión. También se producirá un error si MultiSubnetFailover se usa y SQL Server devuelve una respuesta de 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 de SQL Server Native Client que actualmente usa la creación de reflejo de la base de datos en un escenario de varias subredes, debe quitar la Failover_Partner propiedad de conexión y reemplazarla por MultiSubnetFailover establecida Yes en y reemplazar el nombre del servidor en la cadena de conexión por un agente de escucha de grupo de disponibilidad. Si una cadena de conexión utiliza Failover_Partner y MultiSubnetFailover=Yes, el controlador generará un error. Sin embargo, si una cadena de conexión utiliza Failover_Partner y MultiSubnetFailover=No (o ApplicationIntent=ReadWrite), la aplicación utilizará la creación de reflejo de la base de datos.

El controlador devolverá un error si se usa la creación de reflejo de la base de datos en la base de datos principal del grupo de disponibilidad y si MultiSubnetFailover=Yes se usa en la cadena de conexión que se conecta a una base de datos principal en lugar de a un agente de escucha de grupo de disponibilidad.

Especificación de la intención de la aplicación

Cuando ApplicationIntent=ReadOnlyes , el cliente solicita una carga de trabajo de lectura al conectarse a una base de datos habilitada para AlwaysOn. El servidor aplicará el intento en el momento de la conexión y durante una instrucción de base de datos USE pero solo en una base de datos con habilitada para AlwaysOn.

La palabra clave ApplicationIntent no funciona con bases de datos de solo lectura heredadas.

Una base de datos puede permitir o no permitir cargas de trabajo de lectura en la base de datos AlwaysOn de destino. (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:

  1. Debe conectarse siempre a un agente de escucha de grupo de disponibilidad Always On.

  2. La palabra clave de la cadena de conexión ApplicationIntent debe establecerse en ReadOnly.

  3. 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 Server. 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.

ODBC

Se agregaron dos palabras clave de cadena de conexión ODBC para admitir grupos de disponibilidad AlwaysOn en SQL Server Native Client:

  • ApplicationIntent

  • MultiSubnetFailover

Para obtener más información sobre las palabras clave de cadena de conexión ODBC en SQL Server Native Client, vea Uso de palabras clave de cadena de conexión con SQL Server Native Client.

Las propiedades de conexión equivalentes son:

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Para obtener más información sobre las propiedades de conexión ODBC en SQL Server Native Client, vea SQLSetConnectAttr.

La funcionalidad de las ApplicationIntent palabras clave y MultiSubnetFailover se expondrá en el administrador de orígenes de datos ODBC para DSN que usan el controlador de SQL Server Native Client, a partir de SQL Server 2012.

Una aplicación ODBC de SQL Server Native Client puede usar una de las tres funciones para realizar la conexión:

Función Descripción
SQLBrowseConnect La lista de servidores devueltos por SQLBrowseConnect no incluirá VNN. Solo verá una lista de servidores sin indicación de si el servidor es un servidor independiente o un servidor principal o secundario en un clúster de clústeres de conmutación por error de Windows Server (WSFC) que contiene dos o más instancias de SQL Server que se han habilitado para grupos de disponibilidad AlwaysOn. Si se conecta a un servidor y recibe un error, puede deberse a que se ha conectado a un servidor y la ApplicationIntent configuración no es compatible con la configuración del servidor.

Dado SQLBrowseConnect que no reconoce servidores en un clúster de clústeres de conmutación por error de Windows Server (WSFC) que contiene dos o más instancias de SQL Server que se han habilitado para grupos de disponibilidad AlwaysOn, SQLBrowseConnect omite la palabra clave de cadena MultiSubnetFailover de conexión.
SQLConnect SQLConnect admite y ApplicationIntentMultiSubnetFailover a través de un nombre de origen de datos (DSN) o propiedades de conexión.
SQLDriverConnect SQLDriverConnect admite ApplicationIntent y MultiSubnetFailover a través de palabras clave de cadena de conexión, propiedades de conexión o DSN.

OLE DB

OLE DB en SQL Server Native Client no admite la MultiSubnetFailover palabra clave .

OLE DB en SQL Server Native Client admitirá la intención de la aplicación. La intención de la aplicación se comportará igual para las aplicaciones OLE DB que las aplicaciones ODBC (consulte más arriba).

Se ha agregado una palabra clave de cadena de conexión OLE DB para admitir grupos de disponibilidad AlwaysOn en SQL Server Native Client:

  • Application Intent

Para obtener más información sobre las palabras clave de cadena de conexión en SQL Server Native Client, vea Uso de palabras clave de cadena de conexión con SQL Server Native Client.

Las propiedades de conexión equivalentes son:

  • SSPROP_INIT_APPLICATIONINTENT

  • DBPROP_INIT_PROVIDERSTRING

Una aplicación OLE DB de SQL Server Native Client puede usar uno de los métodos para especificar la intención de la aplicación:

IDBInitialize::Initialize
IDBInitialize::Initialize usa el conjunto de propiedades configurado anteriormente para inicializar el origen de datos y crear el objeto de origen de datos. Especifique la intención de la aplicación como una propiedad de proveedor o como parte de la cadena de propiedades extendidas.

IDataInitialize::GetDataSource
IDataInitialize::GetDataSource toma una cadena de conexión de entrada que puede contener la Application Intent palabra clave .

IDBProperties::GetProperties
IDBProperties::GetProperties recupera el valor de la propiedad que está establecida actualmente en el origen de datos. Puede recuperar el valor a través de Application Intent la propiedad DBPROP_INIT_PROVIDERSTRING y SSPROP_INIT_APPLICATIONINTENT propiedad.

IDBProperties::SetProperties
Para establecer el valor de la ApplicationIntent propiedad, llame a IDBProperties::SetProperties pasando la SSPROP_INIT_APPLICATIONINTENT propiedad con el valor "ReadWrite" o "ReadOnly" o DBPROP_INIT_PROVIDERSTRING la propiedad con el valor que contiene "ApplicationIntent=ReadOnly" o "ApplicationIntent=ReadWrite".

Puede especificar la intención de la aplicación en el campo Propiedades de intención de aplicación de la pestaña Todo del cuadro de diálogo Propiedades de vínculo de datos .

Cuando se establecen conexiones implícitas, la conexión implícita usará la configuración de intención de la aplicación de la conexión primaria. Del mismo modo, varias sesiones creadas a partir del mismo origen de datos heredarán la configuración de intención de la aplicación del origen de datos.

Véase también

Características de SQL Server Native Client
Usar palabras clave de cadena de conexión con SQL Server Native Client

  • Last updated on