Alta disponibilidad y recuperación ante desastres en Linux y macOS
Los controladores ODBC para Linux y macOS admiten Grupos de disponibilidad Always On. Para más información sobre Grupos de disponibilidad AlwaysOn, consulte:
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)
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 particular en la cadena de conexión. Si una aplicación ODBC en Linux o macOS se conecta a una base de datos en un grupo de disponibilidad que realiza la conmutación por error, se pierde la conexión original. La aplicación debe abrir una nueva conexión para que siga funcionando después de la conmutación por error.
Los controladores ODBC en Linux y macOS iteran secuencialmente a través de todas las direcciones IP asociadas a un nombre de host de DNS si el usuario no se conecta a un cliente de escucha de grupo de disponibilidad. Si la primera dirección IP del servidor DNS que se devuelve no se puede conectar, estas iteraciones pueden llevar mucho tiempo.
Al conectarse a una escucha de grupo de disponibilidad, el controlador trata de establecer conexiones con todas las direcciones IP en paralelo. Si un intento de conexión se realiza correctamente, el controlador descarta todos los intentos de conexión pendiente.
Nota
Dado que se puede producir un error de conexión debido a la conmutación por error de un grupo de disponibilidad, se recomienda implementar la lógica de reintento de conexión. Vuelva a intentar realizar una conexión que no se ha podido establecer hasta que vuelva a conectarse. 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 establecer una conexión con un grupo de disponibilidad.
Conexión con MultiSubnetFailover
Especifique siempre MultiSubnetFailover=Yes
al conectarse a un cliente de escucha de grupo de disponibilidad de SQL Server 2012 (11.x) o a una instancia de clúster de conmutación por error de SQL Server 2012 (11.x). MultiSubnetFailover
permite una conmutación por error más rápida en todos los grupos de disponibilidad y una instancia de clúster de SQL Server 2012 (11.x).
Esta propiedad de conexión también reduce considerablemente el tiempo de conmutación por error en las topologías AlwaysOn de una y varias subredes. Durante una conmutación por error de varias subredes, el cliente intentará establecer conexiones en paralelo. Durante una conmutación por error de una subred, el controlador volverá a tratar de establecer la conexión TCP de manera drástica.
La propiedad de conexión MultiSubnetFailover
indica que la aplicación se implementa en un grupo de disponibilidad o una instancia de clúster de conmutación por error. El controlador trata de conectarse a la base de datos de la instancia de SQL Server principal tratando de conectarse a todas las direcciones IP.
Cuando se conecta con MultiSubnetFailover=Yes
, el cliente reintenta la conexión TCP más deprisa que los intervalos de retransmisión TCP predeterminados del sistema operativo. MultiSubnetFailover=Yes
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 de AlwaysOn. MultiSubnetFailover=Yes
se aplica a instancias de clúster de conmutación por error y grupos de disponibilidad de una y varias subredes.
Utilice MultiSubnetFailover=Yes
al conectarse a una instancia de clúster de conmutación por error o una escucha de grupo de disponibilidad. De lo contrario, el rendimiento de la aplicación puede verse afectada adversamente.
Recomendaciones
Cuando se conecta a un servidor de un grupo de disponibilidad o una instancia de clúster de conmutación por error:
Especifique
MultiSubnetFailover=Yes
para mejorar el rendimiento cuando se conecte a un grupo de disponibilidad de una sola subred o varias subredes.Especifique el agente de escucha del grupo de disponibilidad como el servidor en la cadena de conexión.
No se puede conectar a una instancia de SQL Server configurada con más de 64 direcciones IP.
Tanto la autenticación SQL Server como la autenticación Kerberos se pueden usar con
MultiSubnetFailover=Yes
sin que el comportamiento de la aplicación se vea afectado.Puede aumentar el valor de
loginTimeout
para tener en cuenta el tiempo de conmutación por error y reducir los reintentos de conexión de la aplicación.No se admiten transacciones distribuidas.
Si no está activado el enrutamiento de solo lectura, no se podrá conectar a una ubicación de réplica secundaria en un grupo de disponibilidad 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
y la ubicación de réplica secundaria está configurada para acceso de solo lectura.
Una conexión produce 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
.
Especificación de la intención de aplicación
Puede especificar la palabra clave ApplicationIntent
en la cadena de conexión. Los valores asignables son ReadWrite
(el valor predeterminado) o ReadOnly
.
Al establecer ApplicationIntent=ReadOnly
, el cliente solicita una carga de trabajo de lectura al conectarse. El servidor aplicará la intención en el momento de la conexión y durante una instrucción de base de datos USE
.
La palabra clave ApplicationIntent
no funciona con bases de datos de solo lectura heredadas.
Destinos de ReadOnly
Cuando una conexión elige ReadOnly
, la conexión se asigna a cualquiera de las siguientes configuraciones especiales que pueden existir para la base de datos:
Siempre activada Una base de datos puede permitir o denegar la lectura de las cargas de trabajo en la base de datos de grupo de disponibilidad de destino. Esta opción se controla mediante la cláusula
ALLOW_CONNECTIONS
de las instrucciones de Transact-SQLPRIMARY_ROLE
ySECONDARY_ROLE
.
Si ninguno de esos destinos especiales está disponible, se lee desde la base de datos normal.
La palabra clave ApplicationIntent
habilita 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, se aplica lo siguiente:
Debe conectarse a un cliente de escucha del grupo de disponibilidad Always On.
La palabra clave de la cadena de conexión
ApplicationIntent
debe establecerse enReadOnly
.El administrador de bases de datos debe configurar el grupo de disponibilidad para habilitar el enrutamiento de solo lectura.
Varias conexiones que utilizan cada una el enrutamiento de solo lectura podrían no conectarse 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 cliente 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 que la conexión a la principal. Esto se debe a que el enrutamiento de solo lectura se conecta primero a la principal y, luego, busca la mejor instancia secundaria legible que esté disponible. Debido a estos múltiples pasos, debe aumentar el tiempo de espera de login
a 30 segundos como mínimo.
Sintaxis de ODBC
Dos palabras clave de cadena de conexión ODBC admiten Grupos de disponibilidad Always On:
ApplicationIntent
MultiSubnetFailover
Para más información sobre las palabras clave de cadena de conexión ODBC, consulte la sección Usar palabras clave de cadena de conexión con SQL Server Native Client.
Los atributos de conexión equivalentes son estos:
SQL_COPT_SS_APPLICATION_INTENT
SQL_COPT_SS_MULTISUBNET_FAILOVER
Para más información sobre los atributos de conexión de ODBC, vea SQLSetConnectAttr.
Una aplicación de ODBC que usa Grupos de disponibilidad AlwaysOn puede utilizar una de las dos funciones para realizar la conexión:
Función | Descripción |
---|---|
Función SQLConnect | SQLConnect admite ApplicationIntent y MultiSubnetFailover mediante un nombre del origen de datos (DSN) o un atributo de conexión. |
Función SQLDriverConnect | SQLDriverConnect admite ApplicationIntent y MultiSubnetFailover mediante DSN, una palabra clave de cadena de conexión o un atributo de conexión. |
Vea también
Palabras clave de cadena de conexión y nombres de orígenes de datos (DSN)