Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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.
Defina MultiSubnetFailover=True quando o destino é Base de Dados SQL do Azure, Azure SQL Managed Instance, base de dados SQL no Microsoft Fabric, um ouvinte de grupo de disponibilidade ou uma instância de cluster de failover. O driver tenta ligações TCP a todos os endereços IP resolvidos em paralelo e usa a primeira ligação que consegue. Se a aplicação estiver ligada a uma base de dados que faz failover, a ligação original é quebrada e a aplicação tem de abrir uma nova ligação para continuar a funcionar após o failover.
Quando o DNS resolve para um endereço, MultiSubnetFailover=True não cria tentativas adicionais de ligação paralela, por isso é seguro em alvos de IP único.
Os drivers aceitam True, 1 ou Yes, em qualquer dos casos, e passam a opção para o driver ODBC subjacente. Eles tratam qualquer outro valor como Falso sem reportar um erro, por isso um valor mal escrito desativa silenciosamente a opção.
O MultiSubnetFailover tem os seguintes limites:
Não podes usá-lo sobre um protocolo que não seja o TCP.
A ligação a uma instância do SQL Server configurada com mais de 64 endereços IP falha.
Não é possível utilizá-lo com espelhamento de base de dados. Não a definas quando o cadeia de ligação também usa Failover_Partner, ou quando te ligas a uma réplica principal em vez de um ouvinte de grupo de disponibilidade. Para mais informações, consulte Atualização para Utilização de Clusters Multi-Subredes a partir de Espelhamento de Base de Dados.
Para Base de Dados SQL do Azure serverless com autopausa ativada, se definires LoginTimeout, usa pelo menos 60 segundos. Uma base de dados em pausa automática recomeça na primeira tentativa de ligação, e essa tentativa pode falhar com o erro 40613 enquanto a base de dados recomeça, pelo que a aplicação tem de tentar novamente. Para mais informações, veja 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)
A Resolução IP de Rede Transparente (TNIR) é o mecanismo legado de recurso multi-IP do controlador ODBC, controlado pela opção de ligação TransparentNetworkIPResolution e ativado por defeito.
Siga as orientações da secção anterior e defina MultiSubnetFailover=True para os alvos aí listados. Quando MultiSubnetFailover=True, o driver tenta estabelecer ligações TCP a todos os endereços IP resolvidos em paralelo. A opção TransparentNetworkIPResolution não afeta a sequência de ligação, por isso não precisas de a definir ou considerar na cadeia de ligação.
Para a referência completa sobre a interação entre o TNIR e MultiSubnetFailover, consulte Utilizar a Resolução IP de Rede Transparente com o Controlador ODBC.
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 o espelhamento da base de dados para um cenário multissub-rede, remova a propriedade de ligação Failover_Partner e substitua-a por MultiSubnetFailover definida como True. Substitua o nome do servidor na cadeia de ligação por um ouvinte de grupo de disponibilidade. Se uma cadeia de ligação contiver Failover_Partner e MultiSubnetFailover=True, o controlador gera um erro. No entanto, se uma cadeia de ligação utilizar Failover_Partner e MultiSubnetFailover=False (ou ApplicationIntent=ReadWrite), a aplicação utiliza espelhamento de bases de dados.
O driver devolve um erro se usar espelhamento de base de dados na réplica primária do grupo de disponibilidade, e se usar MultiSubnetFailover=True na cadeia de ligação que se liga a uma réplica 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 impõe a intenção no momento da ligação e durante uma USE instrução de base de dados.
A palavra-chave ApplicationIntent não funciona com bases de dados antigas só de 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 através da utilização da cláusula
ALLOW_CONNECTIONSdas instruções Transact-SQLPRIMARY_ROLEeSECONDARY_ROLE.
Se nenhum desses alvos especiais estiver disponível, a base de dados regular é consultada.
A palavra-chave ApplicationIntent permite o encaminhamento só de leitura.
Roteio de somente leitura
O encaminhamento só de leitura é uma funcionalidade que pode garantir a disponibilidade de uma réplica de uma base de dados só de leitura. Para permitir o encaminhamento apenas de leitura, aplicam-se todas as seguintes condições:
Tem de estabelecer ligação a um listener do grupo de disponibilidade Always On.
A
ApplicationIntentpalavra-chave da cadeia de conexão deve ser definida comoReadOnly.O administrador da base de dados deve configurar o grupo de disponibilidade para ativar 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 só de leitura se liguem à mesma réplica só de leitura ao não passar uma escuta do grupo de disponibilidade na palavra-chave da cadeia de ligação Server. Em vez disso, especifique o nome da instância somente leitura.
O encaminhamento só de leitura pode demorar mais tempo do que estabelecer ligação ao servidor 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 estas várias etapas, deve aumentar o seu login timeout para, pelo menos, 30 segundos.