Compatibilidad con recuperación ante desastres de alta disponibilidad

DescargarDescargar controlador para PHP

En este tema se describe la compatibilidad de Controladores de Microsoft para PHP para SQL Server, agregada en la versión 3.0, con recuperación ante desastres de alta disponibilidad.

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.

La propiedad de conexión MultiSubnetFailover indica que la aplicación se está implementando en un grupo de disponibilidad o una instancia de clúster de conmutación por error y que el controlador intentará conectarse a la base de datos en la instancia principal de SQL Server mediante un intento de conexión a todas las direcciones IP. Al conectarse a un agente de escucha de grupo de disponibilidad de SQL Server o una instancia de clúster de conmutación por error de SQL Server, especifique siempre MultiSubnetFailover=True. Si la aplicación 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 nueva para seguir trabajando tras la conmutación por error.

Puede encontrar detalles completos sobre los grupos de disponibilidad Always On en la página de documentación de recuperación ante desastres de alta disponibilidad.

Resolución de IP de red transparente (TNIR)

La resolución de IP de red transparente (TNIR) es una revisión de la característica MultiSubnetFailover existente. Afecta la secuencia de conexión del controlador cuando la primera dirección IP resuelta del nombre de host no responde y hay varias direcciones IP asociadas con el nombre de host. La opción de conexión correspondiente es TransparentNetworkIPResolution. Junto con MultiSubnetFailover, proporciona las cuatro secuencias de conexión siguientes:

  • TNIR habilitado y MultiSubnetFailover deshabilitado: se intenta una IP, seguida de todas las direcciones IP en paralelo.
  • TNIR habilitado y MultiSubnetFailover habilitado: todas las direcciones IP se intentan en paralelo.
  • TNIR deshabilitado y MultiSubnetFailover deshabilitado: todas las direcciones IP se intentan una tras otra.
  • TNIR deshabilitado y MultiSubnetFailover habilitado: todas las direcciones IP se intentan en paralelo.

TNIR está habilitado de forma predeterminada y MultiSubnetFailover, deshabilitado de forma predeterminada.

Este es un ejemplo de cómo habilitar TNIR y MultiSubnetFailover mediante el controlador PDO_SQLSRV:

<?php
$serverName = "yourservername";
$username = "yourusername";
$password = "yourpassword";
$connectionString = "sqlsrv:Server=$serverName; TransparentNetworkIPResolution=Enabled; MultiSubnetFailover=yes";
try {
    $conn = new PDO($connectionString, $username, $password, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION));
    // your code 
    // more of your code
    // when done, close the connection
    unset($conn);
} catch(PDOException $e) {
    print_r($e->errorInfo);
}
?>

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 usa la creación de reflejo de la base de datos en un escenario de varias subredes, quite la propiedad de conexión Failover_Partner y reemplácela por MultiSubnetFailover establecida en True, así como también reemplace 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 usa Failover_Partner y MultiSubnetFailover=true, el controlador generará un error. En cambio, si una cadena de conexión usa Failover_Partner y MultiSubnetFailover=false (o ApplicationIntent=ReadWrite), la aplicación usará la creación de reflejo de la base de datos.

Si la creación de reflejo de la base de datos se usa en la base de datos principal del grupo de disponibilidad y MultiSubnetFailover=true 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, el controlador devolverá un error.

Especificar el intento de la aplicación

Puede especificarse la palabra clave ApplicationIntent en la cadena de conexión. Los valores asignables son ReadWrite o ReadOnly. El valor predeterminado es ReadWrite.

Cuando 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:

  • Always On

    • Una base de datos puede permitir o denegar la lectura de las cargas de trabajo en la base de datos de destino Always On. Esta opción se controla mediante la cláusula ALLOW_CONNECTIONS de las instrucciones Transact-SQL PRIMARY_ROLE y SECONDARY_ROLE.
  • Replicación geográfica:

  • Escalado horizontal de lectura

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 siempre a un agente de escucha de grupo de disponibilidad Always On.

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

  • El administrador de bases de datos debe configurar el grupo de disponibilidad para habilitar el enrutamiento de solo lectura.

Es posible que varias conexiones, cada una 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. Puede asegurarse de que todas las solicitudes de solo lectura se conecten a la misma réplica de solo lectura. Para ello, no pase un cliente de escucha del grupo de disponibilidad a la palabra clave Server 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 que la conexión a la principal. La espera más larga 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 inicio de sesión a 30 segundos como mínimo.

Consulte también

Conexión al servidor