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

Perguntas frequentes: Compartilhamento com MongoDB

Nesta página

  • O sharding é apropriado para uma nova implementação?
  • Posso selecionar uma chave de fragmentação diferente depois de fragmentar uma coleção?
  • Por que meus documentos não são distribuídos entre os shards?
  • Como o mongos detecta alterações na configuração do cluster fragmentado?
  • O que writebacklisten significa no log?
  • Como o mongos utiliza conexões?

Este documento responde a perguntas frequentes sobre compartilhamento. Consulte também a seção Fragmentação no manual, que fornece uma visão geral da fragmentação, incluindo detalhes sobre:

Às vezes. No entanto, se o conjunto de dados couber em um único servidor, é recomendado começar com uma implantação sem fragmentos, visto que há poucas vantagens ao realizar fragmentação em conjuntos de dados pequenos.

Suas opções para alterar uma chave de shard dependem da versão do MongoDB que você está executando:

Dica

Veja também:

O balanceador começa a distribuir dados entre os shards quando a distribuição de chunks atinge determinados limites. Consulte Limites de Migração.

Além disso, o MongoDB não poderá mover um bloco se o número de documentos no bloco exceder um determinado número. Consulte Número máximo de documentos por bloco para migração e Indivisible/JumboChunks.

As instâncias mongos mantêm um cache do banco de banco de dados de configuração que contém os metadados do cluster fragmentado.

mongos atualiza seu cache preguiçosamente emitindo uma solicitação para um shard e descobrendo que seus metadados estão desatualizados. Para forçar o mongos para recarregar seu cache, você pode executar o comando flushRouterConfig em cada mongos diretamente.

O ouvinte de write-back é um processo que abre uma longa pesquisa para retransmitir as gravações de volta de um mongod ou mongos após as migrações para garantir que elas não tenham ido para o servidor errado. O ouvinte de writeback envia writebacks para o servidor correto, se necessário.

Essas mensagens são uma parte importante da infraestrutura de sharding e não devem causar preocupação.

Cada instância do mongos mantém um conjunto de conexões para os membros do cluster fragmentado. As solicitações do cliente usam essas conexões uma de cada vez; ou seja, as solicitações não são multiplexadas ou pipelined.

Quando as solicitações do cliente forem concluídas, o mongos retornará a conexão com o pool. Esses pools não diminuem quando o número de clientes diminui. Isto pode levar a um mongos não utilizado com um grande número de conexões abertas. Se o mongos não estiver mais em uso, é seguro reiniciar o processo para fechar as conexões existentes.

Para retornar estatísticas agregadas relacionadas a todos os pools de conexão de saída usados pelo mongos, conecte mongosh ao mongos e execute o comando connPoolStats :

db.adminCommand("connPoolStats");

Consulte a seção Utilização de recursos do sistema do documento Configurações de ulimit sistemas para implementações autogerenciadas do UNIX .

Voltar

Concurrency