Suporte a alta disponibilidade e recuperação de desastres

Artigo
06/02/2023

Este tópico aborda o suporte do Drivers da Microsoft para PHP para SQL Server (adicionado na versão 3.0) para alta disponibilidade e recuperação de desastre.

Com a versão 3.0 dos Drivers da Microsoft para PHP e para SQL Server será possível especificar o ouvinte de um grupo de alta disponibilidade e de recuperação de desastre ou de uma instância de cluster de failover como servidor na cadeia de conexão.

A propriedade de conexão MultiSubnetFailover indica que o aplicativo está sendo implantado em um grupo de disponibilidade ou em uma Instância de Cluster de Failover. E que o driver tentará se conectar ao banco de dados na instância primária do SQL Server ao tentar se conectar a todos os endereços IP. Sempre especifique MultiSubnetFailover=True ao se conectar a um ouvinte do grupo de disponibilidade ou a uma Instância de Cluster de Failover do SQL Server. Caso o aplicativo esteja conectado a um banco de dados Always On que faça failover, a conexão original será interrompida e o aplicativo deverá abrir uma nova conexão para continuar trabalhando após o failover.

Detalhes completos sobre grupos de disponibilidade Always On podem ser encontrados na página de documentos Alta Disponibilidade e Recuperação de Desastre.

Resolução IP de Rede Transparente (TNIR)

O TNIR (Resolução IP de Rede Transparente) é uma revisão do recurso MultiSubnetFailover existente. Ele afeta a sequência de conexão do driver quando o primeiro IP resolvido do nome do host não responder e quando existem vários IPs associados ao nome do host. A opção de conexão correspondente é TransparentNetworkIPResolution. Junto com MultiSubnetFailover, ele fornecerá as quatro seguintes sequências de conexão:

TNIR habilitado e MultiSubnetFailover desabilitado: um IP é tentado, seguido por todos os IPs em paralelo
TNIR habilitado e MultiSubnetFailover habilitado: todos os IPs são tentados em paralelo
TNIR desabilitado e MultiSubnetFailover desabilitado: todos os IPs são tentados um após o outro
TNIR desabilitado e MultiSubnetFailover habilitado: todos os IPs são tentados em paralelo

O TNIR é habilitado por padrão e o MultiSubnetFailover é desabilitado por padrão.

Este é um exemplo de como habilitar o TNIR e o MultiSubnetFailover usando o driver 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);
}
?>

Atualizando para usar clusters de várias sub-redes a partir do espelhamento de banco de dados

Um erro de conexão ocorrerá se as palavras-chave de conexão MultiSubnetFailover e Failover_Partner estiverem presentes na cadeia de conexão. Também ocorrerá um erro caso MultiSubnetFailover seja usado e o SQL Server retornar uma resposta de parceiro de failover indicando que ele faz parte de um par de espelhamento de banco de dados.

Ao atualizar um aplicativo PHP que atualmente usa o espelhamento de banco de dados para um cenário de várias sub-redes, remova a propriedade de conexão Failover_Partner e substitua-a por MultiSubnetFailover definido como True. Substitua também o nome do servidor na cadeia de conexão por um ouvinte de grupo de disponibilidade. Se uma cadeia de conexão usa Failover_Partner e MultiSubnetFailover=true, o driver gerará um erro. No entanto, se uma cadeia de conexão usar Failover_Partner e MultiSubnetFailover=false (ou ApplicationIntent=ReadWrite), o aplicativo usará o espelhamento de banco de dados.

O driver retornará um erro se o espelhamento de banco de dados for usado no banco de dados primário no AG e se MultiSubnetFailover=true for usado na cadeia de conexão que se conecta a um banco de dados primário, em vez de ao ouvinte de um grupo de disponibilidade.

Especificar a intenção do aplicativo

Você pode especificar a palavra-chave ApplicationIntent na sua cadeia de conexão. Os valores atribuíveis são ReadWrite (o padrão) ou ReadOnly.

Quando você define ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao se conectar. O servidor impõe a intenção no momento da conexão e durante uma instrução do banco de dados USE.

A palavra-chave ApplicationIntent não funciona com bancos de dados herdados somente leitura.

Destinos de ReadOnly

Quando uma conexão escolhe ReadOnly, ela é atribuída a qualquer uma das configurações especiais que podem existir para o banco de dados:

Always On. Um banco de dados pode permitir ou não cargas de trabalho de leitura no banco de dados do grupo de disponibilidade de destino. Essa opção é controlada usando a cláusula ALLOW_CONNECTIONS das instruções do Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.
Replicação geográfica
Escala de leitura

Se nenhum desses destinos especiais estiver disponível, o banco de dados regular será lido.

A palavra-chave ApplicationIntent permite o roteamento somente leitura.

Roteamento somente leitura

O roteamento somente leitura é um recurso que pode garantir a disponibilidade de uma réplica somente leitura de um banco de dados. Para habilitar o roteamento somente leitura, todos os itens a seguir se aplicam:

Você deve se conectar a um ouvinte do grupo de disponibilidade Always On.
A palavra-chave de cadeia de conexão ApplicationIntent deve ser definida como ReadOnly.
O grupo de disponibilidade deve ser configurado pelo administrador de banco de dados para permitir o roteamento somente leitura.

Várias conexões que usam roteamento somente leitura podem se conectar à mesma réplica somente leitura. Alterações na sincronização de banco de dados ou alterações na configuração de roteamento de servidor podem resultar em conexões de cliente com réplicas somente leitura diferentes.

Você pode garantir que todas as solicitações somente leitura conectem-se à mesma réplica somente leitura, não transmitindo um ouvinte de grupo de disponibilidade à palavra-chave de cadeia de conexão Server. Em vez disso, especifique o nome da instância somente leitura.

O roteamento somente leitura pode levar mais tempo do que se conectar ao principal. Isso é porque o roteamento somente leitura se conecta primeiro à instância primária e, em seguida, procura a melhor instância secundária legível disponível. Devido a essas várias etapas, você deve aumentar seu tempo limite do login para no mínimo 30 segundos.

Consulte Também

Conectando-se ao servidor