Suporte a alta disponibilidade e recuperação de desastres

Baixar o driver PHP

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.

A partir da versão 3.0 dos Drivers da Microsoft para PHP para SQL Server, é possível especificar o ouvinte de um grupo de disponibilidade para alta disponibilidade e recuperação de desastres ou 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 tentando se conectar a todos os endereços IP. Sempre especifique MultiSubnetFailover=True ao conectar-se a um listener de 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: é feita uma tentativa com um IP, seguida por tentativas com todos os IPs em paralelo
  • TNIR habilitado e MultiSubnetFailover habilitado: todos os endereços IP são testados em paralelo
  • TNIR desativado e MultiSubnetFailover desativado: todos os IPs são testados 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 do grupo de disponibilidade (AG) e se MultiSubnetFailover=true for usado na string de conexão usada para se conectar a um banco de dados primário, em vez de a um listener de 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 legados somente de 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:

Se nenhum desses alvos especiais estiver disponível, será feita a leitura do banco de dados regular.

A palavra-chave ApplicationIntent permite o roteamento de somente leitura.

Roteamento somente para leitura

O roteamento para somente leitura é uma funcionalidade 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 do Always On.

  • A palavra-chave de cadeia de conexão ApplicationIntent deve ser definida como ReadOnly.

  • O administrador de banco de dados deve configurar o grupo de disponibilidade para habilitar o roteamento de somente leitura.

Várias conexões que usam roteamento somente leitura podem não se conectar todas à 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 de somente leitura.

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

Conteúdo relacionado

  • Last updated on