Fragmentos
Um fragmento contém um subconjunto de dados fragmentados para um aglomerado fragmentado. Juntos, os fragmentos do cluster mantêm todo o conjunto de dados para o cluster.
Os shards devem ser implementados como um conjunto de réplica para fornecer redundância e alta disponibilidade.
Importante
Os clusters fragmentados usam o write concern "majority" de preocupação de gravação para muitas operações internas. O uso de um arbiter em um cluster fragmentado é desaconselhado devido a problemas de desempenho com definir de réplicas de PSA.
Usuários, clientes ou aplicativos só devem se conectar diretamente a um shard para realizar operações administrativas e de manutenção locais.
A realização de queries em um único shard só retorna um subconjunto de dados. Conecte-se ao mongos para executar operações em nível de cluster, inclusive operações de leitura ou gravação.
Importante
O MongoDB não garante que dois chunks contíguos residam em um único shard.
Primary shard
Cada banco de dados em um cluster fragmentado tem um primary shard que contém todas as collections não fragmentadas desse banco de dados. Cada banco de dados tem seu próprio fragmento primário. O fragmento primário não tem relação com o principal em um conjunto de réplica.
O mongos seleciona o primary shard ao criar um novo banco de dados selecionando o shard no cluster que tem a menor quantidade de dados. mongos utiliza o campo totalSize retornado pelo comando listDatabases como parte dos critérios de seleção.
Para alterar o fragmento primário de um banco de dados, utilize o comando movePrimary. O processo de migração do primary shard pode levar um tempo significativo para ser concluído, e você não deve acessar as collections associadas ao database até que ele seja concluído. Dependendo da quantidade de dados migrados, a migração pode afetar as operações gerais do cluster. Considere o impacto nas operações de cluster e na carga de rede antes de tentar alterar o fragmento primário.
Quando você implanta um novo cluster fragmentado com shards que foram usados anteriormente como conjuntos de réplicas, todos os bancos de dados existentes continuam a residir em seus conjuntos de réplicas originais. Bancos de dados criados posteriormente podem residir em qualquer shard no cluster.
Status do shard
Utilize o método sh.status() no mongosh para ter uma visão geral do cluster. Esses relatórios incluem qual fragmento é o primário para o banco de dados e a distribuição de partes nos fragmentos. Consulte o método sh.status() para obter mais detalhes.
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.
Consulte Implantar cluster fragmentado autogerenciado com autenticação de arquivo de chave para obter um tutorial sobre como implantar um cluster fragmentado seguro.
Usuários locais do shard
Cada fragmento oferece suporte ao RBAC ( Role-Based Access Control in Self-Managed Deployments ) para restringir o acesso não autorizado aos dados e às operações do fragmento. Inicie cada mongod na réplica configurada com a opção --auth para impor o RBAC. Como alternativa, aplicar a autenticação interna/de associação autogerenciada para segurança dentro do cluster também permite controles de acesso do usuário via RBAC.
Cada shard tem seus próprios usuários locais do shard. Esses usuários não podem ser usados em outros shards, nem podem ser usados para se conectar ao cluster por meio de um mongos.
Consulte Habilitar controle de acesso em implantações autogerenciadas para obter um tutorial sobre como habilitar a adição de usuários a uma implantação do MongoDB habilitada para RBAC.