Seleção e monitoramento de servidores
Nesta página
Seleção e monitoramento de servidores
Antes que qualquer operação possa ser executada, a biblioteca PHP do MongoDB deve primeiro selecionar um servidor a partir da topologia (por exemplo conjunto de réplicas, cluster fragmentado). A seleção de um servidor requer uma visão precisa da topologia, portanto, a extensão monitora regularmente os servidores aos quais está conectada.
Na maioria dos outros drivers, a descoberta e o monitoramento do servidor são tratados por um thread em background; no entanto, o driver PHP é de thread único e deve, portanto, realizar o monitoramento entre as operações iniciadas pelo aplicação.
Considere o seguinte exemplo de aplicativo:
/** * When constructing a Client, the library creates a MongoDB\Driver\Manager * object from the extension. In turn, the extension will either create a * libmongoc client object (and persist it according to the constructor * parameters) or re-use a previously persisted client. * * Assuming a new libmongoc client was created, the host name(s) in the * connection string must be resolved via DNS. Likewise, if the connection * string includes a mongodb+srv scheme, SRV/TXT records must be resolved. * Following DNS resolution, the driver should then have a list of one or * more hosts to which it can connect. This is referred to as the seed list. * * If a previously persisted client was re-used, no DNS resolution is needed * and there will likely already be connections and topology state associated * with the client. * * Drivers perform no further IO when constructing a client, so control is * returned the the PHP script. */ $client = new MongoDB\Client('mongodb://a.example.com:27017/?replicaSet=rs0'); /** * The library creates a MongoDB\Database object from the Client. This does * not entail any IO, as the Database and Collection objects only associate * a database or namespace with a Client object, respectively. */ $database = $client->test; /** * The library creates an internal object for this operation and must select * a server to use for executing that operation. * * If this is the first operation on the underlying libmongoc client, it must * first discover the topology. It does so by establishing connections to any * host(s) in the seed list (this may entail TLS and OCSP verification) and * issuing "hello" commands. * * In the case of a replica set, connecting to a single host in the seed list * should allow the driver to discover all other members in the replica set. * In the case of a sharded cluster, the driver will start with an initial * seed list of mongos hosts and, if SRV polling is utilized, may discover * additional mongos hosts over time. * * If the topology was already initialized (i.e. this is not the first * operation on the client), the driver may still need to perform monitoring * (i.e. "hello" commands) and refresh its view of the topology. This process * may entail adding or removing hosts from the topology. * * Once the topology has been discovered and any necessary monitoring has * been performed, the driver may select a server according to the rules * outlined in the server selection specification (e.g. applying a read * preference, filtering hosts by latency). */ $database->command(['ping' => 1]);
Embora o aplicativo tenha apenas algumas linhas de PHP, há bastante coisa acontecendo nos bastidores! Para os leitores interessados, esse processo é apresentado com mais detalhes nos seguintes documentos:
Modo de thread único na documentação da libmongoc
Descoberta e monitoramento doservidor MongoDB especificação
Seleção do Servidor MongoDB especificação
Opções de connection string
Existem várias opções de string de conexão relevantes para a seleção e o monitoramento do servidor .
connectTimeoutMS
connectTimeoutMS especifica o limite para estabelecer uma conexão com um servidor e o tempo limite do soquete para monitoramento do servidor (comandos hello ). Esse padrão é de 10 segundos para drivers de thread único, como PHP.
Quando um servidor atinge o tempolimite durante o monitoramento, ele não será verificado novamente até pelo menos cinco segundos ( CooldownMS ) decorrido. Esse tempo limite destina-se a evitar que os drivers de thread único bloqueiem para connectTimeoutMS em cada verificação subsequente após um erro.
Os aplicativos podem definir essa opção como um pouco acima da maior latência entre os servidores no cluster. Por exemplo, se o maior tempo de ping entre o servidor de aplicativos PHP e um servidor de banco de dados for de 200 ms, pode ser adequado especificar um tempo limite de um segundo. Isso permitiria tempo suficiente para estabelecer uma conexão e monitorar um servidor acessível, além de reduzir significativamente o tempo de detecção de um servidor inacessível.
heartbeatFrequencyMS
heartbeatFrequencyMS determina a frequência com que o monitoramento deve ocorrer. Isso tem como padrão 60 segundos para drivers de thread único e pode ser definido com um valor tão baixo quanto 500 ms.
serverSelectionTimeoutMS
serverSelectionTimeoutMS determina a quantidade máxima de tempo a gastar no loop de seleção do servidor. O padrão é 30 segundos, mas os aplicativos normalmente falharão mais cedo se serverSelectionTryOnce for true e um valor menor connectTimeoutMS estiver em vigor.
O padrão original foi estabelecido em um momento em que as eleições de conjuntos de réplicas demoravam muito mais para serem concluídas. Os aplicativos podem considerar a possibilidade de definir essa opção como um pouco mais do que o tempo de conclusão esperado para uma eleição. Por exemplo, AsEleições do Conjunto de Réplicas declaram que as eleições normalmente não excederão 12 segundos, portanto, um 15tempo limite segundos pode ser razoável. Os aplicativos que se conectam a um cluster fragmentado podem considerar um valor ainda menor, pois mongos isola o driver das eleições.
Dito isto, serverSelectionTimeoutMS geralmente não deve ser definido como um valor menor que connectTimeoutMS.
serverSelectionTryOnce
serverSelectionTryOnce determina se o driver deve parar após a primeira tentativa de seleção de servidor com falha ou continuar esperando até que serverSelectionTimeoutMS seja atingido. O padrão do PHP é true, o que permite que o driver "falhe rapidamente" quando um servidor não pode ser selecionado (por exemplo nenhum primário durante um failover).
Em geral, o comportamento padrão é desejável para aplicativos da Web de alto tráfego, pois significa que o processo do worker não será bloqueado em um loop de seleção de servidor e, em vez disso, poderá retornar uma resposta de erro e continuar imediatamente a atender a outra solicitação. Além disso, outros recursos de driver, como leituras e gravações repetíveis, ainda podem permitir que os aplicativos evitem erros transitórios, como um failover.
Dito isto, os aplicativos que priorizam a resiliência em vez do tempo de resposta (e a utilização do pool de trabalhadores) podem querer especificar false para serverSelectionTryOnce.
socketCheckIntervalMS
socketCheckIntervalMS determina com que frequência um soquete deve ser verificado (usando um comando ping ) se não tiver sido usado recentemente. Esse padrão é de 5 segundos e é intencionalmente menor do que heartbeatFrequencyMS para melhor permitir que drivers de thread único recuperem conexões perdidas.
socketTimeoutMS
socketTimeoutMS determina a quantidade máxima de tempo para gastar lendo ou gravando em um soquete. Como o monitoramento de servidor usa connectTimeoutMS para seus tempos limite de soquete, socketTimeoutMS se aplica somente às operações executadas pelo aplicativo.
socketTimeoutMS o padrão é 5 minutos; no entanto, é provável que uma solicitação da web PHP seja encerrada mais cedo devido a max_execution_time, que é padronizado para 30 segundos para SAPIs da web. Em um ambiente CLI, onde max_execution_time é ilimitado por padrão, é mais provável que socketTimeoutMS possa ser alcançado.
Observação
socketTimeoutMS não está diretamente relacionado à seleção e monitoramento do servidor ; no entanto, é frequentemente associada às outras opções e, portanto, deve ser mencionada.