Implemente um cluster fragmentado autogerenciado com autenticação de keyfile
Nesta página
Visão geral
Para aplicar o controle de acesso em umcluster fragmentado do requer configuração:
Segurança entre componentes do cluster usando Autenticação interna.
Segurança entre conectar clientes e o cluster usando Controles de acesso do usuário.
Para este tutorial, cada membro do cluster fragmentado deve usar o mesmo mecanismo de autenticação interna e configurações. Isto significa aplicar autenticação interna em cada mongos
e mongod
no cluster.
O tutorial a seguir usa um arquivo-chave para habilitar a autenticação interna.
Forçar a autenticação interna também força o controle de acesso do usuário. Para se conectar ao conjunto de réplicas, clientes como mongosh
precisam usar uma conta de usuário. Consulte Controle de acesso.
CloudManager e OpsManager
Se você estiver usando o Cloud Manager ou o Ops Manager para gerenciar sua implantação, consulte o respectivo Manual do Cloud Manager ou o Manual do Ops Manager para impor a autenticação.
Considerações
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Vinculação IP
Binários do MongoDB, mongod
e mongos
, ligam-se ao localhost
por padrão.
Segurança de arquivos-chave
Os arquivos-chave são formas mínimas de segurança e são mais adequados para ambientes de teste ou desenvolvimento. Para ambientes de produção, recomendamos usar certificados x.509.
Controle de acesso
Este tutorial aborda a criação do número mínimo de usuários administrativos somente no banco de dados admin
. Para a autenticação do usuário, o tutorial usa o mecanismo de autenticação SCRAM padrão. Os mecanismos de segurança de resposta a desafios são mais adequados para ambientes de teste ou desenvolvimento. Para ambientes de produção, recomendamos o uso de certificados x.509 ou Autenticação de Proxy LDAP autogerenciada (disponível apenas para MongoDB Enterprise) ou Autenticação Kerberos em Implantações Autogerenciadas (disponível apenas para MongoDB Enterprise).
Para obter detalhes sobre a criação de usuários para mecanismos de autenticação específicos, consulte as páginas específicas do mecanismo de autenticação.
Consulte ➤ Configurar o controle de acesso baseado em roles para obter as melhores práticas para criação e gerenciamento de usuários.
Usuários
Em geral, para criar usuários para um cluster fragmentado, é preciso conectar ao mongos
e adicionar os usuários do cluster fragmentado.
No entanto, algumas operações de manutenção exigem conexões diretas com fragmentos específicos em um cluster fragmentado. Para executar essas operações, você deve se conectar diretamente ao fragmento e autenticar como um usuário administrativo local do fragmento.
Os usuários locais do shard existem apenas no shard específico e só devem ser usados para manutenção e configuração específicas do shard. Você não pode se conectar ao mongos
com usuários locais do shard.
Este tutorial requer a criação de usuários de cluster fragmentado, mas inclui etapas opcionais para adicionar usuários locais de shards.
Consulte a documentação de segurança Usuários em implementações autogerenciadas para obter mais informações.
Sistema operacional
Este tutorial utiliza os programas mongod
e mongos
. Os usuários do Windows devem usar os programas mongod.exe
e mongos.exe
.
Distribuir um cluster fragmentado com controle de acesso a arquivos-chave
Os seguintes procedimentos envolvem criar um novo cluster fragmentado que consiste em um mongos
, os servidores de configuração e dois shards.
Importante
Para evitar atualizações de configuração devido a alterações de endereço IP, use nomes de host DNS em vez de endereços IP. É particularmente importante usar um nome de host DNS em vez de um endereço IP ao configurar membros de conjunto de réplicas ou membros de cluster fragmentado.
Use nomes de host em vez de endereços IP para configurar cluster em um horizonte de rede dividido. Começando no MongoDB 5.0, nós configurados apenas com um endereço IP falham na validação de inicialização e não são iniciados.
Criar o arquivo-chave
Com a autenticação de keyfile, cada instância mongod
ou mongos
no cluster fragmentado usa o conteúdo do keyfile como a senha compartilhada para autenticar outros nós do sistema. Somente as instâncias mongod
ou mongos
com o keyfile correto podem entrar no cluster fragmentado.
Observação
Os arquivos de chaves para autenticação de associação interna usam o formato YAML para permitir várias chaves em um só arquivo. O formato YAML aceita:
Uma única string de chave (igual às versões anteriores)
Uma sequência de strings de chave
O formato YAML é compatível com os arquivos-chave de chave única existentes que usam o formato de arquivo de texto.
O comprimento de uma chave deve estar entre 6 e 1.024 caracteres e só pode conter caracteres no conjunto base64. Todos os membros do cluster fragmentado devem compartilhar pelo menos uma chave comum.
Observação
Em sistemas UNIX, o arquivo-chave não deve ter permissões de grupo ou mundiais. Em sistemas Windows, as permissões do arquivo-chave não são verificadas.
Você pode gerar um arquivo-chave usando qualquer método de sua escolha. Por exemplo, a operação a seguir usa openssl
para gerar uma cadeia complexa pseudo-aleatória de 1024 caracteres para ser usada como senha compartilhada. Em seguida, ele usa chmod
para alterar as permissões do arquivo e fornecer permissões de leitura somente para o proprietário do arquivo:
openssl rand -base64 756 > <path-to-keyfile> chmod 400 <path-to-keyfile>
Consulte Keyfiles para obter detalhes adicionais e requisitos para usar keyfiles.
Distribuir o arquivo de chave
Copie o arquivo de chave para cada servidor hospedando os membros do cluster fragmentado. Certifique-se de que o usuário que executa as instâncias mongod
ou mongos
seja o proprietário do arquivo e possa acessá-lo-chave.
Evite armazenar o arquivo-chave em mídias de armazenamento que possam ser facilmente desconectadas do hardware que hospeda as instâncias mongod
ou mongos
, como um pen drive ou um dispositivo de armazenamento conectado à rede.
Criar o Conjunto de Réplicas do Servidor de Configuração
As seguintes etapas distribuem um conjunto de réplicas do servidor de configuração.
Para um sistema de produção, implementa um conjunto de réplicas de servidor de configuração com pelo menos três membros. Para fins de teste, você pode criar um conjunto de réplicas de um único membro.
Inicie cada mongod
no conjunto de réplicas do servidor de configuração de configuração. Inclua a configuração keyFile
. A configuração keyFile
impõe a Autenticação Interna/Associação Autogerenciada e o Controle de Acesso Baseado em Função em Sistemas Autogerenciados.
Você pode especificar as configurações mongod
por meio de um arquivo de configuração ou da linha de comando.
Arquivo de configuração
Se estiver usando um arquivo de configuração, defina security.keyFile
para o caminho do arquivo-chave, sharding.clusterRole
para configsvr
e replication.replSetName
para o nome desejado do conjunto de réplicas do servidor de configuração.
security: keyFile: <path-to-keyfile> sharding: clusterRole: configsvr replication: replSetName: <setname>
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique a configuração net.bindIp
.
Inicie o mongod
especificando a opção --config
e o caminho para o arquivo de configuração.
mongod --config <path-to-config-file>
Linha de comando
Se utilizar os parâmetros da linha de comando, inicie o mongod
com os parâmetros --keyFile
, --configsvr
e --replSet
.
mongod --keyFile <path-to-keyfile> --configsvr --replSet <setname> --dbpath <path>
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip
.
Conecte-se a um nó do conjunto de réplicas pela interface localhost.
Conecte mongosh
a uma das instâncias mongod
pela interface localhost. Você deve executar mongosh
na mesma máquina física que a instância mongod
.
A interface localhost só está disponível porque nenhum usuário foi criado para o sistema. A interface localhost fecha após a criação do primeiro usuário.
O método rs.initiate()
inicia o conjunto de réplicas e pode utilizar um documento de configuração do conjunto de réplica opcional. No documento de configuração do conjunto de réplicas, inclua:
O
_id
. O parâmetro_id
deve corresponder ao parâmetro--replSet
passado paramongod
.O campo
members
. O campomembers
é uma array e requer um documento por cada membro do conjunto de réplicas.O campo
configsvr
. O campoconfigsvr
deve ser configurado paratrue
para o conjunto de réplicas do servidor de configuração.
Consulte Configuração do conjunto de réplicas autogerenciadas para mais informações sobre documentos de configuração do conjunto de réplicas.
Inicie o conjunto de réplicas utilizando o método rs.initiate()
e um documento de configuração:
rs.initiate( { _id: "myReplSet", configsvr: true, members: [ { _id : 0, host : "cfg1.example.net:27019" }, { _id : 1, host : "cfg2.example.net:27019" }, { _id : 2, host : "cfg3.example.net:27019" } ] } )
Observação
Para usar o conjunto de réplicas do servidor de configuração (CSRS) nesse procedimento, primeiro você deve aguardar até que ele conclua a inicialização. Se o CSRS não tiver inicializado, causará NotYetInitialized
erros.
Depois que o conjunto de réplicas do servidor de configuração (CSRS) for iniciado e ativado, prossiga para criar os conjuntos de réplicas de shards.
Crie os conjuntos de réplicas shard
Para um sistema de produção, use um conjunto de réplicas com pelo menos três membros. Para fins de teste, você pode criar um conjunto de réplicas de um único membro.
Essas etapas incluem procedimentos opcionais para adicionar usuários locais de shard. Executá-los agora garante que haja usuários disponíveis para cada shard para realizar a manutenção no nível do shard.
Inicie cada nó do conjunto de réplicas com o controle de acesso habilitado.
A execução de um mongod
com o parâmetro keyFile
força a autenticação interna autogerenciada/associação e o controle de acesso baseado em roles em sistemas autogerenciados.
Inicie cada mongod
no conjunto de réplicas usando um arquivo de configuração ou a linha de comando.
Arquivo de configuração
Se estiver usando um arquivo de configuração, defina a opção security.keyFile
como o caminho do arquivo de chaves, replication.replSetName
como o nome desejado do conjunto de réplicas e a opção sharding.clusterRole
como shardsvr
.
security: keyFile: <path-to-keyfile> sharding: clusterRole: shardsvr replication: replSetName: <replSetName> storage: dbPath: <path>
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique a configuração net.bindIp
.
Inicie o mongod
especificando a opção --config
e o caminho para o arquivo de configuração.
mongod --config <path-to-config-file>
Linha de comando
Se usar a linha de comando, ao iniciar o componente especifique os parâmetros --keyFile
, replSet
e --shardsvr
, como no seguinte exemplo:
mongod --keyFile <path-to-keyfile> --shardsvr --replSet <replSetName> --dbpath <path>
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip
.
Conecte-se a um nó do conjunto de réplicas pela interface localhost.
Conecte mongosh
a uma das instâncias mongod
pela interface localhost. Você deve executar mongosh
na mesma máquina física que a instância mongod
.
A interface localhost só está disponível porque nenhum usuário foi criado para o sistema. A interface localhost fecha após a criação do primeiro usuário.
Inicie o conjunto de réplicas.
A partir do mongosh
, execute o método rs.initiate()
.
rs.initiate()
pode pegar um documento opcional de configuração do conjunto de réplicas. No documento de configuração do conjunto de réplicas, inclua:
O campo
_id
definido com o nome do conjunto de réplicas especificado na opçãoreplication.replSetName
ou--replSet
.A array
members
com um documento por cada membro do conjunto de réplicas.
O exemplo a seguir inicia um conjunto de réplicas de três nós.
rs.initiate( { _id : "myReplSet", members: [ { _id : 0, host : "s1-mongo1.example.net:27018" }, { _id : 1, host : "s1-mongo2.example.net:27018" }, { _id : 2, host : "s1-mongo3.example.net:27018" } ] } )
rs.initiate()
desencadeia uma eleição e elege um dos nós para ser o primary.
Conecte-se ao primary antes de continuar. Use rs.status()
para localizar o nó primary.
Crie o administrador de usuário local do fragmento (opcional).
Importante
Depois de criar o primeiro usuário, a exceção de local não estará mais disponível.
O primeiro usuário deve ter privilégios para criar outros usuários, como um usuário com userAdminAnyDatabase
. Isso garante que você possa criar usuários adicionais depois que a exceção de Localhost em implantações autogerenciadas fecha.
Se pelo menos um usuário não tiver privilégios para criar usuários, depois que a exceção localhost for fechada, talvez você não consiga criar ou modificar usuários com novos privilégios e, portanto, não consiga acessar as operações necessárias.
Adicione um usuário utilizando o método db.createUser()
. O usuário deve ter pelo menos o role userAdminAnyDatabase
no banco de dados do admin
.
Você deve estar conectado ao primary para criar usuários.
O exemplo a seguir cria o usuário fred
com o role userAdminAnyDatabase
no banco de dados do admin
.
Importante
As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.
Dica
Você pode usar o método passwordPrompt()
em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo
.
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
Digite a senha quando solicitado. Consulte Funções do usuário de banco de dados para obter uma lista completa das funções integradas relacionadas às operações de administração do banco de dados.
Autentique-se como administrador de usuário local do fragmento (opcional).
Autenticar no banco de dados do admin
.
No mongosh
, use db.auth()
para se autenticar. Por exemplo, abaixo há uma autenticação como administrador do usuário fred
:
Dica
Você pode usar o método passwordPrompt()
em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo
.
db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password
Como alternativa, conecte uma nova instância do mongosh
ao membro do conjunto de réplicas do primário utilizando os parâmetros -u <username>
, -p <password>
e --authenticationDatabase
.
mongosh -u "fred" -p --authenticationDatabase "admin"
Se você não especificar a senha para a opção de linha de comando -p
, o mongosh
solicitará a senha.
Crie o administrador do cluster local do shard (opcional).
O usuário administrador de cluster local de shard tem a funçãoclusterAdmin
, que fornece privilégios que permitem acesso a operações de replicação.
Para uma lista completa de funções relacionadas com operações de conjunto de réplicas, consulte Funções de Administração de Cluster.
Crie um usuário de administrador do cluster e atribua o role do clusterAdmin
no banco de dados do admin
:
Dica
Você pode usar o método passwordPrompt()
em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo
.
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
Digite a senha quando solicitado.
Veja as Roles de Administração de Cluster para obter uma lista completa de roles integrados relacionados às operações de conjunto de réplicas e operações de cluster fragmentado.
Conecte um mongos
ao cluster fragmentado
Conecte um ao mongos
cluster
Inicie um mongos
especificando o keyfile por meio de um arquivo de configuração ou de um parâmetro de linha de comando.
Arquivo de configuração
Se estiver usando um arquivo de configuração, defina security.keyFile
como o caminho do arquivo de chaves e sharding.configDB
como o nome do conjunto de réplicas e pelo menos um nó do conjunto de réplicas no formato <replSetName>/<host:port>
.
security: keyFile: <path-to-keyfile> sharding: configDB: <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique a configuração net.bindIp
.
Inicie o mongos
especificando a opção --config
e o caminho para o arquivo de configuração.
mongos --config <path-to-config>
Linha de comando
Se utilizar parâmetros da linha de comando, inicie o mongos
e especifique os parâmetros --keyFile
e --configdb
.
mongos --keyFile <path-to-keyfile> --configdb <configReplSetName>/cfg1.example.net:27019,cfg2.example.net:27019,...
Inclua opções adicionais, conforme necessário, para sua configuração. Por exemplo, se você deseja que clientes remotos se conectem à sua implantação ou se os membros da implantação forem executados em hosts diferentes, especifique o --bind_ip
.
Conecte a um pela interface mongos
localhost.
Conecte mongosh
a uma das instâncias mongos
pela interface localhost. Você deve executar mongosh
na mesma máquina física que a instância mongos
.
A interface localhost só está disponível porque nenhum usuário foi criado para o sistema. A interface localhost fecha após a criação do primeiro usuário.
Crie o administrador do usuário.
Importante
Depois de criar o primeiro usuário, a exceção de local não estará mais disponível.
O primeiro usuário deve ter privilégios para criar outros usuários, como um usuário com userAdminAnyDatabase
. Isso garante que você possa criar usuários adicionais depois que a exceção de Localhost em implantações autogerenciadas fecha.
Se pelo menos um usuário não tiver privilégios para criar usuários, depois que a exceção localhost for fechada, você não poderá criar ou modificar usuários e, portanto, talvez não consiga executar as operações necessárias.
Adicione um usuário utilizando o método db.createUser()
. O usuário deve ter pelo menos o role userAdminAnyDatabase
no banco de dados do admin
.
Importante
As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.
O exemplo seguinte cria o usuário fred
no banco de dados do admin
:
Dica
Você pode usar o método passwordPrompt()
em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo
.
admin = db.getSiblingDB("admin") admin.createUser( { user: "fred", pwd: passwordPrompt(), // or cleartext password roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] } )
Consulte Roles do utilizador de banco de dados para obter uma lista completa das roles integradas e relacionadas às operações de administração do banco de dados.
Autenticar como administrador do usuário.
Utilize o db.auth()
para autenticar como o administrador de usuário para criar usuários adicionais:
Dica
Você pode usar o método passwordPrompt()
em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo
.
db.getSiblingDB("admin").auth("fred", passwordPrompt()) // or cleartext password
Digite a senha quando solicitado.
Como alternativa, conecte uma nova sessão mongosh
ao membro do conjunto de réplicas de destino usando os parâmetros -u <username>
, -p <password>
e --authenticationDatabase "admin"
. Você deve usar a Exceção de Localhost em Sistemas Autogerenciados para se conectar ao mongos
.
mongosh -u "fred" -p --authenticationDatabase "admin"
Se você não especificar a senha para a opção de linha de comando -p
, o mongosh
solicitará a senha.
Criar usuário administrativo para o gerenciamento de cluster
O usuário de administrador do cluster tem a role clusterAdmin
, que concede acesso a operações de replicação e fragmentação.
Crie um usuário do clusterAdmin
no banco de dados do admin
.
O exemplo seguinte cria o usuário ravi
no banco de dados do admin
.
Importante
As senhas devem ser aleatórias, longas e complexas para garantir a segurança do sistema e evitar ou atrasar o acesso malicioso.
Dica
Você pode usar o método passwordPrompt()
em conjunto com vários métodos/comandos de autenticação/gerenciamento de usuário para solicitar a senha em vez de especificar a senha diretamente na chamada de método/comando. No entanto, você ainda pode especificar a senha diretamente como faria com versões anteriores do shell mongo
.
db.getSiblingDB("admin").createUser( { "user" : "ravi", "pwd" : passwordPrompt(), // or cleartext password roles: [ { "role" : "clusterAdmin", "db" : "admin" } ] } )
Veja as Roles de Administração de Cluster para obter uma lista completa de roles integrados relacionados às operações de conjunto de réplicas e operações de cluster fragmentado.
Criar usuários adicionais (opcional).
Crie usuários para permitir que os clientes conectem e acessem o cluster fragmentado. Consulte Roles do utilizador do banco de dados para roles internos disponíveis, como read
e readWrite
. Você também pode querer usuários administrativos adicionais. Para obter mais informações sobre os usuários, consulte Usuários em implantações autogerenciadas.
Para criar usuários adicionais, você deve autenticar como um usuário com papéis do userAdminAnyDatabase
ou userAdmin
.
Adicionar shards ao cluster
Para prosseguir, você deve estar conectado ao mongos
e autenticado como o usuário administrador do cluster para o cluster fragmentado.
Observação
Este é o administrador do cluster para o cluster fragmentado e não o administrador do cluster local do shard.
Para adicionar cada shard ao cluster, utilize o método sh.addShard()
. Se o shard for um conjunto de réplicas, especifique o nome do conjunto de réplicas e especifique um membro do conjunto. Em sistemas de produção, todos os shards devem ser conjuntos de réplicas.
A seguinte operação adiciona um conjunto de réplica de shard único ao cluster:
sh.addShard( "<replSetName>/s1-mongo1.example.net:27017")
A seguinte operação é um exemplo de adição de um fragmento mongod
independente no cluster:
sh.addShard( "s1-mongo1.example.net:27017")
Repita essas etapas até que o cluster inclua todos os shards. Nesse ponto, o cluster fragmentado força o controle de acesso ao cluster, bem como para comunicações internas entre cada componente do cluster fragmentado.
Habilitar o compartilhamento para um reconhecimento de data center
Para prosseguir, você deve estar conectado ao mongos
e autenticado como o usuário administrador do cluster para o cluster fragmentado.
Observação
Este é o administrador do cluster para o cluster fragmentado e não o administrador do cluster local do shard.
Habilitar a fragmentação em um banco de dados torna possível fragmentar collections dentro do banco de dados. Utilize o método sh.enableSharding()
para habilitar a fragmentação no banco de dados de destino.
sh.enableSharding("<database>")
Fragmentar uma Coleção
Para prosseguir, você deve estar conectado ao mongos
e autenticado como o usuário administrador do cluster para o cluster fragmentado.
Observação
Este é o administrador do cluster para o cluster fragmentado e não o administrador do cluster local do shard.
Para fragmentar uma coleção, utilize o método sh.shardCollection()
. Você deve especificar o namespace completo da coleção e um documento contendo a chave de fragmento.
Sua seleção de chave de shard afeta a eficiência do shard, bem como sua capacidade de aproveitar determinados recursos de fragmentação, como zonas. Consulte as considerações de seleção listadas em Escolher uma chave de shard.
Se a collection já contiver dados, você deverá criar um índice na chave de shard usando o método db.collection.createIndex()
antes de usar shardCollection()
.
Se a collection estiver vazia, o MongoDB criará o índice como parte do sh.shardCollection()
.
A seguir, um exemplo do método sh.shardCollection()
:
sh.shardCollection("<database>.<collection>", { <key> : <direction> } )
Próximos passos
Crie usuários para permitir que os clientes se conectem e interajam com o cluster fragmentado.
Consulte Roles de utilizador de banco de dados para roles internas básicas a serem usadas na criação de usuários somente leitura e de leitura e gravação.
x.509 Autenticação interna
Para obter detalhes sobre como usar x.509 para autenticação interna, consulte Usar o certificado x.509 para autenticação de associação com o MongoDB autogerenciado.
Para atualizar da autenticação interna do keyfile para x.509 autenticação interna, consulte Atualizar o MongoDB autogerenciado da autenticação de keyfile para x. Autenticação do 509 .