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.

Defina MultiSubnetFailover=True quando o alvo é Banco de Dados SQL do Azure, Instância Gerenciada de SQL do Azure, SQL database no Microsoft Fabric, um ouvinte de grupo de disponibilidade ou uma instância de cluster de failover. O driver tenta conexões TCP para todos os endereços IP resolvidos em paralelo e usa a primeira conexão que tem sucesso. Se a aplicação estiver conectada a um banco de dados que faz failover, a conexão original é quebrada e a aplicação deve abrir uma nova conexão para continuar funcionando após o failover.

Quando o DNS resolve para um endereço, MultiSubnetFailover=True não cria tentativas adicionais de conexão paralela, então é seguro em alvos de IP único.

Os drivers aceitam True, 1 ou Yes, em qualquer caso, e passam a opção para o driver ODBC subjacente. Eles tratam qualquer outro valor como Falso sem reportar um erro, então um valor com erro de ortografia desativa silenciosamente a opção.

O failover MultiSubnet possui os seguintes limites:

  • Você não pode usá-lo em um protocolo que não seja o TCP.

  • A conexão a uma instância do SQL Server configurada com mais de 64 endereços IP falha.

  • Você não pode usá-lo com espelhamento de banco de dados. Não configure quando o cadeia de conexão também usa Failover_Partner, ou quando você se conecta a uma réplica primária em vez de um ouvinte de grupo de disponibilidade. Para mais informações, veja Atualização para Usar Clusters Multi-Sub-redes a partir do Espelhamento de Banco de Dados.

Para Banco de Dados SQL do Azure serverless com autopausa ativada, se você definir LoginTimeout, use pelo menos 60 segundos. Um banco de dados pausado automaticamente é retomado na primeira tentativa de conexão, e essa tentativa pode falhar com o erro 40613 enquanto o banco de dados recomeça, então a aplicação deve tentar novamente. Para mais informações, consulte Pausa automática e retomada automática.

Para mais informações sobre grupos de disponibilidade Always On, veja O que é um Grupo de Disponibilidade Always On?.

Resolução IP de Rede Transparente (TNIR)

Transparent Network IP Resolution (TNIR) é o recurso multi-IP legado do driver ODBC, controlado pela opção de conexão TransparentNetworkIPResolution e ativado por padrão.

Siga as orientações da seção anterior e defina MultiSubnetFailover=True para os alvos listados lá. Quando MultiSubnetFailover=True, o driver tenta conexões TCP para todos os endereços IP resolvidos em paralelo. A opção TransparentNetworkIPResolution não afeta a sequência de conexão, então você não precisa configurá-la ou considerá-la na cadeia de conexão.

Para a referência completa de interação entre TNIR e MultiSubnetFailover , veja Uso da Resolução IP de Rede Transparente com o Driver ODBC.

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 espelhamento de banco de dados para um cenário multi-sub-rede, remova a propriedade de conexão Failover_Partner e substitua-a por MultiSubnetFailover definido como Verdadeiro. Substitua o nome do servidor na cadeia de conexão por um ouvinte do grupo de disponibilidade. Se um cadeia de conexão usar Failover_Partner e MultiSubnetFailover=True, o driver gera um erro. No entanto, se um cadeia de conexão usar Failover_Partner e MultiSubnetFailover=False (ou ApplicationIntent=ReadWrite), a aplicação utiliza espelhamento de banco de dados.

O driver retorna um erro se você usar espelhamento de banco de dados na réplica primária do grupo de disponibilidade, e se você usar MultiSubnetFailover=True na string de conexão que se conecta a uma réplica primária em vez de a um ouvinte 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