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.
En este tema se describe la compatibilidad de los controladores de Microsoft para PHP para SQL Server con la alta disponibilidad y la recuperación ante desastres, agregada en la versión 3.0.
A partir de la versión 3.0 de los controladores de Microsoft para PHP para SQL Server, puede especificar el agente de escucha del grupo de disponibilidad de un grupo de disponibilidad de recuperación ante desastres de alta disponibilidad o una instancia de clúster de conmutación por error como el servidor en la cadena de conexión.
Establezca MultiSubnetFailover=True cuando el destino sea Azure SQL Database, Azure SQL Managed Instance, una base de datos SQL de Microsoft Fabric, un agente de escucha de grupo de disponibilidad o una instancia de clúster de conmutación por error. El controlador intenta conexiones TCP a todas las direcciones IP resueltas en paralelo y utiliza la primera conexión que consigue funcionar. Si la aplicación está conectada a una base de datos que hace failover, la conexión original se rompe y la aplicación debe abrir una nueva conexión para seguir funcionando tras la failover.
Cuando DNS se resuelve a una dirección, MultiSubnetFailover=True no crea intentos adicionales de conexión paralela, por lo que es seguro en objetivos de una sola IP.
Los controladores aceptan True, 1 o Yes, en cualquier caso, y pasan la opción al controlador ODBC subyacente. Tratan cualquier otro valor como Falso sin reportar un error, por lo que un valor mal escrito desactiva silenciosamente la opción.
MultiSubnetFailover tiene los siguientes límites:
No puedes usarlo sobre un protocolo que no sea TCP.
Falla la conexión a una instancia de SQL Server configurada con más de 64 direcciones IP.
No puedes usarlo con el espejado de bases de datos. No lo configures cuando el cadena de conexión también use Failover_Partner, ni cuando te conectes a una réplica primaria en lugar de un oyente de grupo de disponibilidad. Para más información, véase Actualización para usar clústeres de varias subredes desde el espejado de bases de datos.
Para Azure SQL Database serverless con pausa automática activada, si configuras LoginTimeout, usa al menos 60 segundos. Una base de datos en pausa automática se reanuda en el primer intento de conexión, y ese intento puede fallar con el error 40613 mientras la base de datos se reanuda, por lo que la aplicación debe intentarlo de nuevo. Para más información, consulta la pausa automática y la reanudación automática.
Para más información sobre los grupos de disponibilidad Always On, consulta ¿Qué es un Always On Availability Group?.
Resolución transparente de IP en red (TNIR)
La Resolución Transparente de IP de Red (TNIR) es el mecanismo alternativo heredado de varias IP del controlador ODBC, se controla mediante la opción de conexión TransparentNetworkIPResolution y está habilitado de forma predeterminada.
Sigue las indicaciones de la sección anterior y establece MultiSubnetFailover=True para los objetivos que aparecen allí. Cuando MultiSubnetFailover=True, el controlador intenta establecer conexiones TCP a todas las direcciones IP resueltas en paralelo. La opción TransparentNetworkIPResolution no afecta a la secuencia de conexión, así que no necesitas configurarla ni considerarla en la cadena de conexión.
Para obtener la referencia completa sobre la interacción entre TNIR y MultiSubnetFailover, consulte Uso de la resolución transparente de IP de red con el controlador ODBC.
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 palabras clave de conexión MultiSubnetFailover y Failover_Partner se encuentran en la cadena de conexión. También se producirá un error 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.
Al actualizar una aplicación PHP que actualmente utiliza reflejo de la base de datos a un entorno de varias subredes, elimina la propiedad de conexión Failover_Partner y reemplázala por MultiSubnetFailover establecida en True. Sustituye el nombre del servidor en la cadena de conexión por un oyente de grupo de disponibilidad. Si un cadena de conexión usa Failover_Partner y MultiSubnetFailover=True, el controlador genera un error. Sin embargo, si un cadena de conexión utiliza Failover_Partner y MultiSubnetFailover=False (o ApplicationIntent=ReadWrite), la aplicación utiliza espejado de base de datos.
El controlador devuelve un error si usa la duplicación de la base de datos en la réplica principal del grupo de disponibilidad y si usa MultiSubnetFailover=True en la cadena de conexión que conecta con una réplica principal en lugar de con un detector de escucha del grupo de disponibilidad.
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_CONNECTIONSde las instrucciones de Transact-SQLPRIMARY_ROLEySECONDARY_ROLE.
Si ninguno de esos destinos especiales está disponible, se recurre a 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
ApplicationIntentdebe 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 conectarse al servidor principal. Esto se debe a que el enrutamiento de solo lectura se conecta primero a la instancia principal y, luego, busca la mejor instancia secundaria de lectura disponible. Debido a estos múltiples pasos, debe aumentar el tiempo de espera de login a al menos 30 segundos.