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

Servidores de configuração

Nesta página

  • Servidores de configuração do conjunto de réplicas
  • Operações de leitura e gravação em servidores de configuração
  • Disponibilidade do servidor de configuração
  • Metadados de cluster fragmentados
  • Segurança de Cluster Fragmentado
  • Config Shards

Os servidores de configuração armazenam os metadados para umcluster fragmentado do . Os metadados refletem o estado e a organização de todos os dados e componentes dentro do cluster fragmentado. Os metadados incluem a lista de chunks em cada shard e os intervalos que definem os chunks.

As instâncias do mongos armazenam estes dados em cache e os utilizam para rotear operações de leitura e escrita para os fragmentos corretos. O mongos atualiza o cache quando há alterações nos metadados do cluster, como adicionar um fragmento. Os fragmentos também lêem metadados em chunk dos servidores de configuração.

Os servidores de configuração também armazenam informações de configuração de Autenticação em implementações autogerenciadas, como Controle de acesso baseado em Função ou configurações de autenticação interna para o cluster.

O MongoDB também usa os servidores de configuração para gerenciar bloqueios distribuídos.

Cada cluster fragmentado deve ter seus próprios servidores de configuração. Não use os mesmos servidores de configuração para diferentes clusters fragmentados.

Aviso

As operações administrativas conduzidas em servidores de configuração podem ter um impacto significativo no desempenho e na disponibilidade do cluster fragmentado. Dependendo do número de servidores de configuração afetados, o cluster pode ficar somente para leitura ou off-line por um período de tempo.

A partir do MongoDB 8.0, você pode configurar um servidor de configuração para armazenar dados do aplicativo, além dos metadados usuais do cluster fragmentado. O servidor de configuração é então conhecido como fragmento de configuração. Você saberá mais sobre isso mais adiante nesta página, na seção Fragmentos de configuração.

As seguintes restrições se aplicam a uma configuração de conjunto de réplica quando usada para servidores de configuração:

  • Deve ter zero árbitros.

  • Não deve ter membros atrasados.

  • Deve construir índices (ou seja, nenhum membro deve ter a configuração members[n].buildIndexes definida como falsa).

O banco de dados do admin e o banco de dados de banco de dados do config existem nos servidores de configuração.

O banco de dados admin contém as collections relacionadas à autenticação e autorização, bem como as outras system.* collections para uso interno.

O banco de dados config contém as coleções que contêm os metadados de cluster fragmentados. O MongoDB grava dados no banco de dados config quando os metadados são alterados, por exemplo, após a migração ou a divisãode uma parte.

Os usuários devem evitar gravar diretamente no banco de dados de configuração durante a operação ou manutenção normal.

Ao gravar nos servidores de configuração, o MongoDB utiliza uma write concern do "majority".

O MongoDB lê a partir do banco de dados do admin para dados de autenticação e autorização e outros usos internos.

O MongoDB lê a partir do banco de dados do config quando um mongos inicia ou após uma alteração nos metadados, como após uma migração de chunk. Os shards também leem metadados de chunks dos servidores de configuração.

Ao ler dos servidores de configuração do conjunto de réplicas, o MongoDB usa um nível de read concern de "majority".

Para que uma operação seja bem-sucedida, a visualização dos metadados no membro específico do shard deve estar atualizada. O shard e o roteador que emite a solicitação devem ter a mesma versão dos metadados dos chunks.

Se os metadados não estiverem atualizados, a operação falhará com o erro StaleConfig e o processo de atualização de metadados será acionado. A atualização dos metadados pode introduzir latência operacional adicional.

Em um secundário, uma atualização de metadados pode levar muito tempo se houver um atraso de replicação. Para leituras secundárias, defina maxStalenessSeconds para minimizar o impacto do atraso de replicação.

Se o conjunto de réplicas do servidor de configuração perder seu primário e não puder eleger um primário, os metadados do cluster se tornarão somente leitura. Você ainda pode ler e gravar dados a partir dos shards, mas nenhuma migração de chunk ou divisão de chunk ocorrerá até que o conjunto de réplicas possa selecionar uma primária.

Em um cluster fragmentado, as instâncias mongod e mongos monitoram os conjuntos de réplicas no cluster fragmentado (por exemplo, conjunto de réplicas de shards, conjunto de réplicas de servidores de configuração).

Se todos os servidores de configuração ficarem indisponíveis, o cluster poderá se tornar inoperável. Para garantir que os servidores de configuração permaneçam disponíveis e intactos, backups de servidores de configuração são críticos. Os dados no servidor de configuração são pequenos em comparação com os dados armazenados em um cluster, e o servidor de configuração tem uma carga de atividade relativamente baixa.

Consulte Um membro do conjunto de réplicas do Config Server fica indisponível para obter mais informações.

Os servidores de configuração armazenam metadados no banco de dados do config .

Importante

Sempre faça backup do banco de dados do config antes de realizar qualquer manutenção no servidor de configuração.

Para acessar o banco de dados do config, emita o seguinte comando em mongosh:

use config

Em geral, você não deve nunca editar o conteúdo do banco de dados do config diretamente. O banco de dados do config contém as seguintes collections:

Para obter mais informações sobre estas coleções e sobre a função delas em agrupamentos fragmentados, consulte a página Banco de dados Config. Consulte a página Operações de leitura e gravação em servidores de configuração para obter mais informações sobre leituras e atualizações dos metadados.

Use a autenticação interna/de associação autogerenciada para impor a segurança dentro do cluster e impedir que componentes não autorizados do cluster acessem o cluster. Você deve iniciar cada mongod no cluster com as configurações de segurança apropriadas 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.

Novidades na versão 8.0.

A partir do MongoDB 8.0, você pode:

  • Configure um servidor de configuração para armazenar os dados do seu aplicativo, além dos metadados usuais do cluster fragmentado. Um servidor de configuração que armazena dados do aplicativo é chamado de fragmento de configuração.

  • Faça a transição de um servidor de configuração entre um shard de configuração e um servidor de configuração dedicado.

Um cluster exige um servidor de configuração, mas ele pode ser um fragmento de configuração em vez de um servidor de configuração dedicado . Usar um shard de configuração reduz o número de nós necessários e pode simplificar seu sistema.

Se o seu aplicação tiver requisitos rigorosos de disponibilidade e resiliência, considere implementar um servidor de configuração dedicado. Um servidor de configuração dedicado oferece isolamento, recursos dedicados e desempenho consistente para operações críticas de cluster.

Você não pode usar o mesmo shard de configuração para vários clusters fragmentados.

Para configurar um servidor de configuração dedicado para ser executado como um shard de configuração, execute o comando transitionFromDedicatedConfigServer .

Para configurar um shard de configuração para ser executado como um servidor de configuração dedicado, execute o comando transitionToDedicatedConfigServer .

Um usuário criado em um fragmento de configuração tem o mesmo comportamento de um usuário criado em um servidor de configuração dedicado.

Para identificar o servidor de configuração como um fragmento de configuração, inspecione o documento na coleção admin.system.version . Neste exemplo, shardName é definido como 'config':

{
_id: 'shardIdentity',
shardName: 'config',
clusterId: ObjectId("<objectID>"),
configsvrConnectionString: '<config server replica set connection string>',
}

O exemplo a seguir recupera um documento de identidade de fragmento de admin.system.version no banco de dados admin:

use admin
db.system.version.find()

Extração de saída:

{
_id: 'shardIdentity',
shardName: 'config',
clusterId: ObjectId("6441bdd6779584849dcac095"),
configsvrConnectionString: 'configRepl/localhost:27007'
}

Se o seu cluster tiver um fragmento de configuração e você precisar fazer o downgrade da versão de compatibilidade de recursos para uma versão anterior a 8.0, conecte-se a mongos e execute este procedimento:

1

Para começar a configurar um fragmento de configuração para ser executado como um servidor de configuração dedicado, execute transitionToDedicatedConfigServer:

db.adminCommand( {
transitionToDedicatedConfigServer: 1
} )
2

Para listar todos os bancos de dados no cluster, execute listDatabases:

db.adminCommand( { listDatabases: 1, nameOnly: true } )

Excluir bancos de dados admin e config.

Para cada banco de dados:

1

Para listar todas as coleções no banco de dados, execute listCollections.

db.adminCommand(
{
listCollections: 1,
nameOnly: true,
filter: { type: { $ne: "view" } }
}
)

Excluir coleções que começam com system.

Para cada coleção restante:

1

Para mover a coleção para um novo fragmento, execute moveCollection:

db.adminCommand(
{
moveCollection: "<database>.<collection>",
toShard: "<new shard>",
}
)
3

Para verificar se o balanceador moveu os dados da coleção fragmentada para fora do servidor de configuração, execute transitionToDedicatedConfigServer novamente:

db.adminCommand( {
transitionToDedicatedConfigServer: 1
} )

A resposta após uma movimentação de dados bem-sucedida contém state: "completed". Se a resposta contiver state: "pendingDataCleanup", aguarde um momento e continue chamando transitionToDedicatedConfigServer até que a resposta do comando contenha state: "completed". Para obter detalhes completos da resposta, consulte removeShard.

4

Para definir a versão de compatibilidade de recursos, execute setFeatureCompatibilityVersion:

db.adminCommand( { setFeatureCompatibilityVersion: "7.0" } )

Voltar

Fragmentos