Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

mongos

Nesta página

  • Processo de Roteamento e Resultados
  • Como o mongos Lida com modificadores de query
  • Leia Preferências e Fragmentos
  • Confirme a Conexão com mongos Instâncias
  • Operações direcionadas vs. operações de transmissão
  • Segurança de Cluster Fragmentado
  • Operações de Metadados
  • Informações adicionais

As instâncias do MongoDB mongos encaminham queries e operações de gravação para fragmentos em um cluster fragmentado. O mongos fornece a única interface para um cluster fragmentado da perspectiva de aplicativos. Os aplicativos nunca se conectam ou se comunicam diretamente com os shards.

O mongos rastreia quais dados estão em qual fragmento, armazenando em cache os metadados dos servidores de configuração. O mongos usa os metadados para rotear operações de aplicativos e clientes para as instâncias mongod. Um mongos não tem estado persistente e consome recursos mínimos do sistema.

A prática mais comum é executar instâncias mongos nos mesmos sistemas que seus servidores de aplicativos, mas você pode manter mongos instâncias nos shards ou em outros recursos dedicados. Consulte também Número de mongos e Distribuição.

Uma instância mongos roteia uma query para um cluster por:

  1. Determinando a lista de fragmentos que devem receber a query.

  2. Estabelecendo um cursor em todos os shards direcionados.

Em seguida, mongos mescla os dados de cada um dos fragmentos direcionados e retorna o documento resultante. Determinados modificadores de query, como classificação, são executados em cada fragmento antes que mongos recupera os resultados.

As operações de aggregation executadas em vários shards podem encaminhar os resultados de volta ao mongos para mesclar os resultados, caso não precisem ser executadas no primary sharddo banco de dados.

Há dois casos em que um pipeline não é elegível para ser executado em mongos.

O primeiro caso ocorre quando a parte de mesclagem do pipeline dividido contém um estágio que deve ser executado em um fragmento específico. Por exemplo, se $lookup exigir acesso a uma coleção não fragmentada no mesmo banco de dados que a coleção fragmentada na qual a agregação está sendo executada, a mesclagem será executada no fragmento que hospeda a coleção não fragmentada.

O segundo caso ocorre quando a parte de mesclagem do pipeline dividido contém um estágio que pode gravar dados temporários no disco, como $group, e o cliente especificou allowDiskUse:true Nesse caso, supondo que não haja outros estágios no pipeline de mesclagem que exijam o primary shard, a mesclagem é executada em um shard selecionado aleatoriamente no conjunto de shards visados pela aggregation.

Para obter mais informações sobre como o trabalho de aggregation é feito na divisão entre os componentes de uma query de cluster fragmentado, use explain:true como parâmetro para a chamada aggregate() . O retorno inclui três objetos JSON:

  • mergeType mostra onde o estágio da fusão acontece ("primaryShard", "anyShard", "specificShard" ou "mongos"). Quando mergeType é specificShard, a saída agregada inclui uma propriedade mergeShard que contém o ID de shard do shard de mesclagem.

  • splitPipeline mostra quais operações em seu pipeline foram executadas em fragmentos individuais.

  • shards mostra o trabalho que cada fragmento fez.

Em alguns casos, quando a chave do fragmento ou um prefixo da chave do fragmento faz parte da query, o mongos executa uma operação direcionada, encaminhando as queries para um subconjunto de fragmentos no cluster.

mongos executa uma operação de difusão para queries que não incluem a chave do fragmento, encaminhando as queries para todos os fragmentos no cluster. Algumas queries que incluem a chave de fragmento ainda podem resultar em uma operação geral, dependendo da distribuição de dados no cluster e da seletividade da query.

Consulte Operações Direcionadas vs. Operações de Transmissão para saber mais sobre operações direcionadas e de transmissão.

Se o resultado da query não for classificado, a instância mongos abrirá um cursor de resultado que "round robins" resultados de todos os cursores nos shards.

Se a query limitar o tamanho do conjunto de resultados utilizando o método do cursor limit(), a instância mongos passará esse limite para os shards e, em seguida, aplicará novamente o limite ao resultado antes de retornar o resultado ao cliente.

Se a query especificar um número de registros a serem ignorados usando o skip() método de cursor , o mongos não poderá passar o pulo para os fragmentos, mas recuperará resultados não ignorados dos fragmentos e ignorará o número apropriado de documentos ao montar o resultado completo.

Quando utilizado em conjunto com um limit(), o mongos passa do limite acrescido do valor do skip() aos shards para melhorar a eficiência dessas operações.

Para agrupamentos fragmentados, o mongos aplica a preferência de leitura ao ler a partir dos fragmentos. O membro selecionado é regido pelas configurações de preferência de leitura e replication.localPingThresholdMs e é reavaliado para cada operação.

Para obter detalhes sobre preferências de leitura e clusters fragmentados, consulte Preferência de leitura e shards

Importante

A partir do MongoDB 8.0, as leituras distribuídas estão obsoletas. As queries que especificam a read preference nearest não usam mais leituras protegidas por padrão. Se você especificar explicitamente uma leitura com hedge, o MongoDB executará uma leitura com hedge e registrará um aviso.

As instâncias de mongos podem proteger leituras que usam preferências de leitura nãoprimary. Com leituras distribuídas, as instâncias de mongos encaminham operações de leitura para dois membros do conjunto de réplicas por cada fragmento consultado e retornam resultados do primeiro respondente por fragmento. A leitura adicional enviada para proteger a operação de leitura usa o valor maxTimeMS de maxTimeMSForHedgedReads.

As leituras distribuídas são suportadas para as seguintes operações:

As leituras com hedge são especificadas por operação como parte da preferência de leitura. As non-primary read preferences suportam leituras protegidas. Consulte Opção de preferência de leitura com hedge.

Para obter detalhes sobre read preference e clusters fragmentados, bem como sobre a seleção de membros, consulte Preferência de leitura e shards.

Por padrão, as instâncias mongos suportam o uso de leituras distribuídas. Para desativar o suporte de uma instância mongos para leituras distribuídas, consulte o parâmetro readHedgingMode. Se o suporte de leituras distribuídas for off, mongos não usará leiturasdistribuídas, independentemente da opção hedge especificada para a preferência de leitura.

O comando serverStatus e seu método correspondente mongosh db.serverStatus() retornam hedgingMetrics.

Para detectar se a instância do MongoDB à qual seu cliente está conectado mongos, use o comando hello. Quando um cliente se conecta a um mongos, hello retorna um documento com um campo msg que contém a cadeia de caracteres isdbgrid. Por exemplo:

{
"isWritablePrimary" : true,
"msg" : "isdbgrid",
"maxBsonObjectSize" : 16777216,
"ok" : 1,
...
}

Se, em vez disso, o aplicativo estiver conectado a um mongod, o documento retornado não incluirá a cadeia de caracteres isdbgrid.

Geralmente, as queries mais rápidas em um ambiente fragmentado são aquelas que mongos rotear para um único fragmento, usando a chave de fragmento e os metadados de cluster do servidor de configuração. Essas operações direcionadas usam o valor da chave de fragmento para localizar o fragmento ou subconjunto de fragmentos que satisfazem o documento de query.

Para queries que não incluem a chave de shard, mongos deve consultar todos os shards, wait por suas responses e, em seguida, retornar o result para o aplicativo. Essas queries de "scatter/gather" podem ser operações de longa duração.

As instâncias mongos transmitem queries para todos os shards da collection , a menos que o mongos possa determinar qual shard ou subconjunto de shards armazena esses dados.

Leia operações para um cluster fragmentado. Os critérios de query não incluem a chave de shard. O roteador de query `'mongos'' deve transmitir a query para todos os shards da collection.

Depois que o mongos recebe respostas de todos os fragmentos, mescla os dados e retorna o documento de resultado. O desempenho de uma operação de transmissão depende da carga geral do cluster, bem como de variáveis como latência de rede, carga de fragmento individual e número de documentos retornados por fragmento. Sempre que possível, privilegie as operações que resultam em operação direcionada em detrimento daquelas que resultam em uma operação de transmissão.

As operações de atualização múltipla são sempre operações de transmissão.

Os métodos updateMany() e deleteMany() são operações de transmissão, a menos que o documento de query especifique a chave de shard completa.

mongos pode rotear queries que incluem a chave de fragmento ou o prefixo de uma chave de fragmento composta para um fragmento específico ou um conjunto de fragmentos. mongos usa o valor da chave do fragmento para localizar o fragmento cujo intervalo inclui o valor da chave do fragmento e direciona a query para o fragmento que contém esse fragmento.

Leia operações para um cluster fragmentado. Os critérios de query incluem a chave de shard. O roteador de query `'mongos'' pode direcionar a query para o shard ou shards apropriados.

Por exemplo, se a chave de shard for:

{ a: 1, b: 1, c: 1 }

O programa mongos pode rotear queries que incluam a chave de fragmento completa ou qualquer um dos seguintes prefixos de chave de fragmento em um fragmento ou conjunto de fragmentos específico:

{ a: 1 }
{ a: 1, b: 1 }

Todas as operações do insertOne() são direcionadas para um fragmento. Cada documento na array insertMany() tem como alvo um único fragmento, mas não há garantia de que todos os documentos na array sejam inseridos em um único fragmento.

Todas as operações updateOne(), replaceOne() e deleteOne() devem incluir a chave de fragmento ou _id no documento de query. O MongoDB retornará um erro se esses métodos forem usados sem a chave fragmentada ou _id.

Dependendo da distribuição de dados no cluster e da seletividade da query, o mongos ainda pode executar uma operação de transmissão para atender estas queries.

Quando um shard recebe uma query, ele utiliza o índice mais eficiente disponível para atender a essa query. O índice usado pode ser o índice de chave de shard ou outro índice elegível presente no shard.

Use a autenticação interna/de associação autogerenciada para reforçar a segurança dentro do cluster e impedir que componentes não autorizados do cluster acessem o cluster. Você deve iniciar cada mongod ou mongos no cluster com as configurações de segurança adequadas para impor a autenticação interna.

A partir do MongoDB 5.3, o SCRAM-SHA-1 não pode ser usado para autenticação intra-cluster. Somente SCRAM-SHA-256 é suportado.

Em versões anteriores do MongoDB, SCRAM-SHA-1 e SCRAM-SHA-256 podem ser usados para autenticação intra-cluster, mesmo que o SCRAM não esteja explicitamente habilitado.

Consulte Implantar cluster fragmentado autogerenciado com autenticação de arquivo de chave para obter um tutorial sobre como implantar um cluster fragmentado seguro.

Os clusters fragmentados oferecem suporte ao controle de acesso baseado em função em implantações autogerenciadas (RBAC) para restringir o acesso não autorizado a dados e operações do cluster. Você deve iniciar cada mongod no cluster, incluindo os servidores de configuração, com a opção --auth para impor o RBAC. Como alternativa, forçar a autenticação interna/de associação autogerenciada para segurança entre clusters também permite controles de acesso do usuário via RBAC.

Com o RBAC imposto, os clientes devem especificar um --username, --password e --authenticationDatabase ao conectar ao mongos para acessar os recursos do cluster.

Cada cluster tem seus próprios usuários de cluster. Esses usuários não podem ser usados para acessar shards individuais.

Consulte Habilitar controle de acesso em implantações autogerenciadas para obter um tutorial sobre como habilitar a adição de usuários a uma implantação do MongoDB habilitada para RBAC.

O mongos utiliza o "majority" write concern para as seguintes operações que afetam os metadados do cluster fragmentado:

Comando
Método

O binário mongos não pode se conectar a instâncias mongod cuja feature compatibility version (fCV) seja maior que a do mongos. Por exemplo, você não pode conectar uma versão do MongoDB 4.0 mongos a um cluster fragmentado do 4.2 com fCV configurado para 4.2. No entanto, você pode conectar um mongos versão do MongoDB 4.0 a um cluster fragmentado 4.2 com fCV definido como 4.0.

mongod inclui um mecanismo de captura de dados de diagnóstico em tempo integral para ajudar os engenheiros do MongoDB a solucionar problemas nos sistemas. Se essa thread falhar, ela encerra o processo de origem. Para evitar as falhas mais comuns, confirme se o usuário que está executando o processo tem permissões para criar o diretório FTDC diagnostic.data. Para mongod, o diretório está dentro de storage.dbPath. Para mongos, ele é paralelo a systemLog.path.

A partir do MongoDB 4.2, o MongoDB adiciona o parâmetro ShardingTaskExecutorPoolReplicaSetMatching. Esse parâmetro determina o tamanho mínimo do pool de conexões da instância mongod / mongos do pool de conexões da instância para cada membro do cluster fragmentado. Este valor pode variar durante o tempo de execução.

mongod e mongos mantêm pools de conexão para cada conjunto de réplicas secundário para cada conjunto de réplicas no cluster fragmentado. Por padrão, esses pools têm um número de conexões que é pelo menos igual ao número de conexões com o primary.

Para modificar, consulte ShardingTaskExecutorPoolReplicaSetMatching.

Para obter mais informações sobre como a fragmentação funciona com as agregações, leia o capítulo sobre fragmentação no e-book Agregações práticas do MongoDB.

Voltar

Config Servers (metadata)