As collections no banco de dados config suportam:
a partir do MongoDB 3.6, sessões causalmente consistentes para standalone, conjuntos de réplicas e clusters fragmentados e gravações com possibilidade de nova tentativa para conjuntos de réplicas e clusters fragmentados.
Observação
Clusters fragmentados podem mostrar collection diferentes no reconhecimento de data center config , dependendo se você se conecta a mongos ou mongod:
Em
mongos, o banco de dadosconfigmostra coleções localizadas nos servidor de configuração, comocollectionsouchunks.No
mongod, o banco de dados doconfigmostra coleções específicas para o fragmento fornecido, comomigrationCoordinatorsourangeDeletions.
Quando um servidor de configuração e um fragmento são hospedados no mesmo nó, mongos pode ter acesso a algumas collection locais do fragmento no reconhecimento de data center config .
Restrições
A partir do MongoDB 5.0, leituras não transacionais não são permitidas na coleção config.transactions com as seguintes preocupação de leitura e opções:
"majority"e a opção afterClusterTime está definidaAo usar um driver do MongoDB e
"majority"em uma sessão causalmente consistente
Importante
O esquema do banco de dados do config é interno e pode mudar entre versões do MongoDB. O banco de dados config não é uma API confiável, e os usuários não devem gravar dados no banco de dados config durante a operação ou manutenção normal.
Observação
Não é possível executar operações de leitura/gravação nas collections do banco de dados config em uma transação de vários documentos.
Collections para dar suporte a operações de cluster fragmentado
Para acessar o banco de dados do config e visualizar a lista de coleções que suportam operações de fragmentação, conecte o mongosh a uma instância do mongos em um agrupamento fragmentado e emita o seguinte:
use config show collections
Observação
Se estiver executando com controle de acesso, certifique-se de ter privilégios que concedam a ação listCollections no banco de dados.
O banco de dados de configuração é principalmente para uso interno e, durante operações normais, você nunca deve inserir ou armazenar dados manualmente nele. No entanto, se você precisar verificar a disponibilidade de gravação do servidor de configuração para um cluster fragmentado, poderá inserir um documento em uma collection de teste (depois de verificar se nenhuma collection desse nome já existe):
Aviso
A modificação do banco de dados do config em um sistema funcional pode levar à instabilidade ou conjuntos de dados inconsistentes. Se você tiver que modificar o banco de dados do config, utilize o mongodump para criar uma cópia de segurança completa do banco de dados do config.
db.testConfigServerWriteAvail.insertOne( { a : 1 } )
Se a operação for bem-sucedida, o servidor de configuração estará disponível para processar gravações.
Versões futuras do servidor podem incluir collections diferentes no banco de dados de configuração, portanto, tenha cuidado ao selecionar um nome para sua collection de teste.
O MongoDB utiliza as seguintes collections no banco de dados do config para suportar a fragmentação:
config.changelogDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
changelogarmazena um documento para cada alteração nos metadados de uma coleção fragmentada.Exemplo
O exemplo a seguir exibe um único registro de uma divisão de parte de uma coleção
changelog:{ "_id" : "<hostname>-<timestamp>-<increment>", "server" : "<hostname><:port>", "clientAddr" : "127.0.0.1:63381", "time" : ISODate("2012-12-11T14:09:21.039Z"), "what" : "split", "ns" : "<database>.<collection>", "details" : { "before" : { "min" : { "<database>" : { $minKey : 1 } }, "max" : { "<database>" : { $maxKey : 1 } }, "lastmod" : Timestamp(1000, 0), "lastmodEpoch" : ObjectId("000000000000000000000000") }, "left" : { "min" : { "<database>" : { $minKey : 1 } }, "max" : { "<database>" : "<value>" }, "lastmod" : Timestamp(1000, 1), "lastmodEpoch" : ObjectId(<...>) }, "right" : { "min" : { "<database>" : "<value>" }, "max" : { "<database>" : { $maxKey : 1 } }, "lastmod" : Timestamp(1000, 2), "lastmodEpoch" : ObjectId("<...>") }, "owningShard" : "<value>" } } Cada documento na coleção
changelogcontém os seguintes campos:config.changelog.clientAddrUma cadeia de caracteres que contém o endereço do cliente, uma instância
mongosque inicia essa alteração.
config.changelog.timeUm carimbo de data/hora ISODate que reflete quando a alteração ocorreu.
config.chunksDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A collection
chunksarmazena um documento para cada chunk no cluster. Considere o seguinte exemplo de um documento para um chunk denominadomydb.foo-a_\"cat\":{ "_id" : "mydb.foo-a_\"cat\"", "lastmod" : Timestamp(2, 1), "uuid": "c025d039-e626-435e-b2d2-c1d436038041", "min" : { "animal" : "cat" }, "max" : { "animal" : "dog" }, "shard" : "shard0004", "history" : [ { "validAfter" : Timestamp(1569368571, 27), "shard" : "shard0004" } ] } Esses documentos armazenam o intervalo de valores para a chave de estilhaço que descreve o chunk nos campos
minemax. Adicionalmente, o camposhardidentifica o fragmento no cluster que "possui" o bloco.
config.collectionsDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
collectionsarmazena um documento para cada coleção fragmentada no cluster. Considerando uma coleção chamadapetsno banco de dadosrecords, um documento na coleçãocollectionsseria semelhante ao seguinte:{ "_id" : "records.pets", "lastmod" : ISODate("2021-07-21T15:48:15.193Z"), "timestamp": Timestamp(1626882495, 1), "key" : { "a" : 1 }, "unique" : false, "lastmodEpoch" : ObjectId("5078407bd58b175c5c225fdc"), "uuid" : UUID("f8669e52-5c1b-4ea2-bbdc-a00189b341da") }
config.databasesDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
databasesarmazena um documento para cada banco de dados no cluster.Para cada banco de dados, o documento correspondente exibe o nome, o primary shard do banco de dados, o status habilitado de fragmentação do banco de dados e uma versão.
{ "_id" : "test", "primary" : "shardA", "partitioned" : true, "version" : { "uuid" : UUID("516a5f79-5eb9-4844-8ee9-b8e9de91b760"), "timestamp" : Timestamp(1626894204, 1), "lastMod" : 1 } } { "_id" : "hr", "primary" : "shardA", "partitioned" : false, "version" : { "uuid" : UUID("8e39d61d-6259-4c33-a5ed-bcd2ae317b6f"), "timestamp" : Timestamp(1626895015, 1), "lastMod" : 1 } } { "_id" : "reporting", "primary" : "shardB", "partitioned" : false, "version" : { "uuid" : UUID("07c63242-51b3-460c-865f-a67b3372d792"), "timestamp" : Timestamp(1626895826, 1), "lastMod" : 1 } } O método
sh.status()retorna essas informações na seção Bancos de dados .
config.lockpingsDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
lockpingsmantém o controle dos componentes ativos no cluster fragmentado. Dado um cluster com ummongosem execução emexample.com:30000, o documento na coleçãolockpingsseria semelhante a:{ "_id" : "example.com:30000:1350047994:16807", "ping" : ISODate("2012-10-12T18:32:54.892Z") }
config.locksDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
locksarmazena as travas distribuídas. O primário do conjunto de réplicas do servidor de configuração usa um bloqueio inserindo um documento na coleçãolocks.{ "_id" : "test.myShardedCollection", "state" : 2, "process" : "ConfigServer", "ts" : ObjectId("5be0b9ede46e4f441a60d891"), "when" : ISODate("2018-11-05T21:52:00.846Z"), "who" : "ConfigServer:Balancer", "why" : "Migrating chunk(s) in collection test.myShardedCollection" } A partir da versão 3.4, o campo
statesempre terá um valor2para impedir que qualquer instânciamongosherdada execute a operação de balanceamento. O campowhenespecifica a hora em que o nó do servidor de configuração se tornou o primary.Na versão 3.4, quando o balanceador está ativo, o balanceador recebe uma trava, como a seguir 3.4 exemplo:
{ "_id" : "balancer", "state" : 2, "ts" : ObjectId("5be0bc6cb20effa83b15baa8"), "who" : "ConfigServer:Balancer", "process" : "ConfigServer", "when" : ISODate("2018-11-05T21:56:13.096Z"), "why" : "CSRS Balancer" } A partir da versão 3.6, o balanceador não usa mais um "bloqueio". Se você atualizou de 3.4 para 3.6, poderá optar por excluir quaisquer documentos
"_id" : "balancer"residuais.
config.migrationCoordinatorsA coleção
migrationCoordinatorsexiste em cada fragmento e armazena um documento para cada migração de parte em andamento deste fragmento para outro fragmento. A migração de parte falha se o documento não puder ser gravado para a maioria dos membros do conjunto de réplica do fragmento.Quando uma migração é concluída, o documento que descreve a migração é excluído da collection.
config.mongosDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A collection
mongosarmazena um documento para cada instânciamongosafiliada ao cluster. As instânciasmongosenviam pings para todos os membros do cluster a cada 30 segundos para que o cluster possa verificar se omongosestá ativo. O campopingmostra o tempo do último ping, enquanto o campouprelata o tempo de atividade domongosa partir do último ping. O cluster mantém essa coleção para fins de relatório.O documento a seguir mostra o status do
mongosem execução noexample.com:27017.{ "_id" : "example.com:27017", "advisoryHostFQDNs" : [ "example.com" ], "mongoVersion" : "4.2.0", "ping" : ISODate("2019-09-25T19:26:52.360Z"), "up" : NumberLong(50), "waiting" : true }
config.rangeDeletionsA coleção
rangeDeletionsexiste em cada fragmento e armazena um documento para cada faixa de parte que contém documentos órfãos. A migração de parte falha se o documento não puder ser gravado para a maioria dos membros do conjunto de réplica do fragmento.Quando a faixa de chunks órfãos é limpa, o documento que descreve a faixa é excluído da collection.
config.settingsDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
settingscontém as seguintes configurações de fragmentação:Tamanho do chunk. Para alterar o tamanho do chunk, consulte Modificar o Tamanho do Chunk em um Cluster Fragmentado. O valor
chunksizeespecificado está em megabytes.Configurações do Balanceador. Para alterar as configurações do balanceador, incluindo o status do balanceador, consulte Gerenciar balanceador de cluster fragmentado.
Começando no MongoDB 4.2:
balancerStarttambém permite a divisão automática para o cluster fragmentado.balancerStoptambém desabilita a divisão automática para o cluster fragmentado.
Autosplit. Para habilitar ou desabilitar o sinalizador de divisão automática, use o método
sh.enableAutoSplit()ou o métodosh.disableAutoSplit()correspondente.Começando no MongoDB 4.2:
balancerStarttambém permite a divisão automática para o cluster fragmentado.balancerStoptambém desabilita a divisão automática para o cluster fragmentado.
A seguir estão alguns documentos de exemplo na coleção
settings:{ "_id" : "chunksize", "value" : 64 } { "_id" : "balancer", "mode" : "full", "stopped" : false } { "_id" : "autosplit", "enabled" : true }
config.shardsDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
shardsrepresenta cada fragmento no cluster em um documento separado, como a seguir:{ "_id" : "shard0000", "host" : "localhost:30000", "state" : 1 } Se o shard for um conjunto de réplicas, o campo
hostexibirá o nome do conjunto de réplicas, depois uma barra e, em seguida, uma lista separada por vírgulas dos nomes de host de cada membro do conjunto de réplicas, como no exemplo a seguir:{ "_id" : "shard0001", "host" : "shard0001/localhost:27018,localhost:27019,localhost:27020", "state" : 1 } Se o shard tiver zonas atribuídas, este documento terá um campo
tags, que contém uma array das zonas às quais está atribuído, como no exemplo a seguir:{ "_id" : "shard0002", "host" : "localhost:30002", "state" : 1, "tags": [ "NYC" ] }
config.tagsDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
tagscontém documentos para cada intervalo de zona no cluster. Os documentos da coleçãotagssão assim:{ "_id" : { "ns" : "records.users", "min" : { "zipcode" : "10001" } }, "ns" : "records.users", "min" : { "zipcode" : "10001" }, "max" : { "zipcode" : "10281" }, "tag" : "NYC" }
config.versionDica
Metadados MongoDB internos
O banco de dados de configuração é interno. Aplicativos e administradores não devem modificar ou depender de seu conteúdo durante a operação normal.
A coleção
versionmantém o número da versão de metadados atual. Essa coleção contém apenas um documento. Por exemplo:{ "_id" : 1, "minCompatibleVersion" : 5, "currentVersion" : 6, "clusterId" : ObjectId("5d8bc01a690d8abbd2014ddd") } Para acessar a coleção
version, você deve usar o métododb.getCollection(). Por exemplo, para recuperar o documento da coleção:db.getCollection("version").find()
Collections para apoiar sessões
Novidade na versão 3.6.
A partir do MongoDB 3.6, o config banco de dados contém as collections internas para suportar sessões causalmente consistentes para autônomos, conjuntos de réplicas e clusters fragmentados e retryable writes e transações para conjuntos de réplicas e clusters fragmentados.
Aviso
Não modifique ou solte manualmente essas collections.
Para acessar essas coleções para uma instância mongod ou mongos , conecte mongosh à instância.
config.system.sessionsA collection do
system.sessionsarmazena registros de sessão que estão disponíveis para todos os membros do sistema.Quando um usuário cria uma sessão em uma instância
mongodoumongos, o registro da sessão existe inicialmente apenas na memória da instância. Periodicamente, a instância sincronizará suas sessões em cache com a collectionsystem.sessions; nesse momento, elas estarão visíveis para todos os membros da implantação.Para visualizar registros na collection
system.sessions, utilize$listSessions.Aviso
Não modifique ou elimine manualmente a collection
system.sessions.Em um cluster fragmentado, a collection
system.sessionsé fragmentada.Ao adicionar um shard ao cluster fragmentado, se o shard a ser adicionado já contiver sua própria collection
system.sessions, o MongoDB soltará a collectionsystem.sessionsdo novo shard durante o processo de adição.A partir da versão 4.4 (e 4.2.7), o MongoDB faz a divisão automática da coleção
system.sessionsem pelo menos 1024 partes e distribui as partes uniformemente entre os fragmentos no cluster.
config.transactionsA collection
transactionsarmazena registros usados para suportar retryable writes e transações que podem ser repetidas para conjuntos de réplicas e cluster fragmentados .Aviso
Não modifique ou elimine manualmente a collection
transactions.