Compatibilidad con recuperación ante desastres de alta disponibilidad

  • Artículo

Descargar controlador 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 Always On 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 dirección IP seguida de todas las direcciones IP en paralelo
  • TNIR habilitado y MultiSubnetFailover habilitado: se intentan todas las direcciones IP en paralelo
  • TNIR habilitado y MultiSubnetFailover deshabilitado: se intentan todas las direcciones IP una tras otra
  • TNIR deshabilitado y MultiSubnetFailover habilitado: se intentan todas las direcciones IP 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.

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:

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 en ReadOnly.

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

Consulte también

Conexión al servidor