Servidores de configuração
Nesta página
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.
Servidores de configuração do conjunto de réplicas
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].buildIndexesdefinida como falsa).
Operações de leitura e gravação em servidores de configuração
O banco de dados do admin e o banco de dados de banco de dados do config existem nos servidores de configuração.
Grava em 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".
Leituras de servidores de configuração
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".
As visualizações de metadados devem estar atualizadas
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.
Disponibilidade do servidor de configuraçã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.
Metadados de cluster fragmentados
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.
Segurança de Cluster Fragmentado
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.
Config Shards
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 fragmento de configuração para vários clusters fragmentados.
Comandos
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 .
Usuários
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.
Confirmar uso do Config Shard
Para confirmar que um cluster fragmentado usa um shard de configuração, execute o comando listShards no admin banco de dados de dados enquanto estiver conectado a um e inspecione a saída de um documento em mongos que _id esteja definido como "config". Se a listShards saída não contiver um documento em que _id esteja definido como "config", o cluster não usará um fragmento de configuração.
O exemplo a seguir executa o comando listShards e tenta localizar um documento em que _id está definido como "config".
db.adminCommand({ listShards: 1 })["shards"].find(element => element._id === "config")
Neste exemplo, o documento retornado tem _id definido como "config", o que confirma que esse cluster usa um shard de configuração.
{ _id: "config", host: "configRepl/localhost:27018", state: 1, topologyTime: Timestamp({ t: 1732218671, i: 13 }), replSetConfigVersion: Long('-1') }
Versão de compatibilidade de recursos de downgrade
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:
Configure um fragmento de configuração para ser executado como um servidor de configuração dedicado.
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 } )
Liste todos os bancos de dados e coleções no cluster.
Para listar todos os bancos de dados no cluster, execute
listDatabases:db.adminCommand( { listDatabases: 1, nameOnly: true } ) Excluir bancos de dados
admineconfig.Para cada banco de dados de dados , liste todas as collections no banco de banco de dados.
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 que não seja do sistema, mova a coleção para um novo shard.
Para mover a coleção para um novo fragmento, execute moveCollection:
db.adminCommand( { moveCollection: "<database>.<collection>", toShard: "<new shard>", } )
Aguarde até que o balanceador mova os dados de coleção fragmentados para fora do servidor de configuração.
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.
Defina a versão de compatibilidade de recursos.
Para definir a versão de compatibilidade de recursos, execute setFeatureCompatibilityVersion:
db.adminCommand( { setFeatureCompatibilityVersion: "7.0" } )