Partilhar via


Suporte para alta disponibilidade, recuperação de desastres

Descarregar o driver PHP

Este tópico discute os drivers Microsoft para PHP para suporte ao SQL Server (adicionados na versão 3.0) para alta disponibilidade e recuperação de desastres.

A partir da versão 3.0 dos Microsoft Drivers for PHP for SQL Server, pode especificar o ouvinte do grupo de disponibilidade de um grupo de disponibilidade de alta disponibilidade, de recuperação de desastres, ou de uma instância de cluster de failover como o servidor na cadeia de ligação.

A propriedade de ligação MultiSubnetFailover indica que a aplicação está a ser implementada num grupo de disponibilidade ou Instância de Cluster de Failover e que o driver tentará ligar-se à base de dados na instância principal do SQL Server tentando ligar-se a todos os endereços IP. Especifique sempre MultiSubnetFailover=True ao ligar-se a um listener de grupo de disponibilidade do SQL Server ou a uma Instância de Cluster de Failover do SQL Server. Se a aplicação estiver ligada a uma base de dados Always On que faz failover, a ligação original é interrompida e a aplicação tem de abrir uma nova ligação para continuar a funcionar após o failover.

Detalhes completos sobre os grupos de disponibilidade Always On podem ser encontrados na página de Documentos de Alta Disponibilidade, Recuperação de Desastres .

Resolução IP de Rede Transparente (TNIR)

A Resolução IP de Rede Transparente (TNIR) é uma revisão da funcionalidade "MultiSubnetFailover" existente. Afeta a sequência de ligação do driver quando o primeiro IP resolvido associado ao nome de anfitrião não responde e existem múltiplos IPs associados ao nome de anfitrião. A opção de ligação correspondente é TransparentNetworkIPResolution. Juntamente com MultiSubnetFailover, fornece as seguintes quatro sequências de ligação:

  • TNIR Ativado e MultiSubnetFailover desativado: Um IP é tentado, seguido por todos os IPs em paralelo
  • TNIR Ativado e MultiSubnetFailover Ativado: Todos os IPs são verificados em paralelo
  • TNIR desativado e MultiSubnetFailover desativado: Todos os IPs são tentados um após o outro
  • TNIR desativado & MultiSubnetFailover ativado: Todos os IPs são testados em paralelo

O TNIR está ativado por defeito, e o MultiSubnetFailover está desativado por defeito.

Este é um exemplo de ativação tanto do TNIR como do 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);
}
?>

Atualização para Utilização de Clusters Multi-Subredes a partir de Espelhamento de Bases de Dados

Ocorrerá um erro de ligação se as palavras-chave MultiSubnetFailover e Failover_Partner connection estiverem presentes na cadeia de ligação. Também ocorrerá um erro se for usado MultiSubnetFailover e o SQL Server devolver uma resposta do parceiro de failover indicando que faz parte de um par de espelhamento da base de dados.

Ao atualizar uma aplicação PHP que atualmente utiliza espelhamento de bases de dados para um cenário multi-sub-rede, remova a propriedade de ligação Failover_Partner e substitua-a por MultiSubnetFailover definida como True e substitua o nome do servidor na cadeia de ligação por um ouvinte de grupo de disponibilidade. Se uma cadeia de ligação usar Failover_Partner e MultiSubnetFailover=true, o driver gerará um erro. No entanto, se uma cadeia de ligação usar Failover_Partner e MultiSubnetFailover=false (ou ApplicationIntent=ReadWrite), a aplicação usará espelhamento de base de dados.

O driver devolverá um erro se for usado espelhamento de base de dados na base de dados primária na AG, e se MultiSubnetFailover=true for usado na cadeia de ligação que se liga a uma base de dados primária em vez de a um ouvinte de grupo de disponibilidade.

Especifique a intenção da aplicação

Podes especificar a palavra-chave ApplicationIntent na tua cadeia de ligação. Os valores atribuíveis são ReadWrite (o padrão) ou ReadOnly.

Quando defines ApplicationIntent=ReadOnly, o cliente solicita uma carga de trabalho de leitura ao ligar. O servidor faz cumprir a intenção no momento da ligação e durante uma USE instrução da base de dados.

A ApplicationIntent palavra-chave não funciona com bases de dados legadas de apenas leitura.

Alvos do ReadOnly

Quando uma ligação escolhe ReadOnly, a ligação é atribuída a qualquer uma das seguintes configurações especiais que possam existir para a base de dados:

  • Sempre ligado. Uma base de dados pode permitir ou não a leitura de cargas de trabalho na base de dados do grupo de disponibilidade alvo. Esta escolha é controlada usando a ALLOW_CONNECTIONS cláusula das PRIMARY_ROLE instruções e SECONDARY_ROLE Transact-SQL.

  • Geo-replication

  • Escalamento horizontal de leituras

Se nenhum desses alvos especiais estiver disponível, a base de dados regular é consultada.

A ApplicationIntent palavra-chave permite o encaminhamento apenas de leitura.

Roteio de somente leitura

O encaminhamento apenas de leitura é uma funcionalidade que pode garantir a disponibilidade de uma réplica somente de leitura de uma base de dados. Para permitir o encaminhamento apenas de leitura, aplicam-se todas as seguintes condições:

  • Deve ligar-se a um ouvinte do grupo de disponibilidade Always On.

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

  • O administrador da base de dados deve configurar o grupo de disponibilidade para permitir o encaminhamento apenas de leitura.

Várias ligações que usam roteamento apenas de leitura podem não se ligar todas à mesma réplica de apenas leitura. Modificações na sincronização da base de dados ou alterações na configuração de roteamento do servidor podem resultar em ligações dos clientes a diferentes réplicas de leitura apenas.

Pode garantir que todos os pedidos apenas de leitura se ligam à mesma réplica de somente leitura ao não passar um ouvinte de grupo de disponibilidade para a Server palavra-chave da cadeia de ligação. Em vez disso, especifique o nome da instância somente leitura.

O encaminhamento só de leitura pode demorar mais do que ligar ao primário. Isto acontece porque o encaminhamento apenas de leitura liga-se primeiro ao primário e depois procura o melhor secundário legível disponível. Devido a estes múltiplos passos, deve aumentar o seu login tempo para pelo menos 30 segundos.

Ver também

Ligação ao Servidor