Definição
reshardCollectionO comando
reshardCollectionaltera a chave de fragmento de uma coleção e altera a distribuição dos seus dados.Observação
Você pode executar o comando
reshardCollectioncomforceRedistribution: truepara remover um shard com jumbo chunks. Como a refragmentação evita as limitações estritas do balanceador, geralmente é o melhor método para remover um fragmento que contém jumbo chunks. Alternativamente, você pode utilizar omoveChunkcomandoforceJumbo: truecom. No entanto, como é uma operação offline, ela pode causar tempo de inatividade.Dica
Em
mongosh, esse comando também pode ser executado por meio do método auxiliarsh.reshardCollection().Os métodos auxiliares são práticos para os usuários
mongosh, mas podem não retornar o mesmo nível de informações que os comandos do banco de dados. Nos casos em que a praticidade não for necessária ou os campos de retorno adicionais forem necessários, use o comando de banco de dados.
Compatibilidade
Esse comando está disponível em implantações hospedadas nos seguintes ambientes:
MongoDB Atlas: o serviço totalmente gerenciado para implantações do MongoDB na nuvem
Observação
Este comando é aceito em todos os clusters do MongoDB Atlas. Para obter informações sobre o suporte do Atlas a todos os comandos, consulte Comandos não suportados.
MongoDB Enterprise: a versão autogerenciada e baseada em assinatura do MongoDB
MongoDB Community: uma versão com código disponível, de uso gratuito e autogerenciada do MongoDB
Sintaxe
O comando tem a seguinte sintaxe:
db.adminCommand( { reshardCollection: "<database>.<collection>", key: { "<shardkey>" }, unique: <boolean>, numInitialChunks: <integer>, collation: { locale: "simple" }, zones: [ { min: { "<document with same shape as shardkey>" }, max: { "<document with same shape as shardkey>" }, zone: <string> | null }, ], forceRedistribution: <bool> } )
Campos de comando
O comando utiliza os seguintes campos:
Campo | Tipo | Descrição | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| string | O namespace da collection a ser refragmentada. Assume o formato | ||||||||
| documento | O documento que especifica o novo campo ou campos a serem usados como a chave de shard.
Defina os valores do campo como:
| ||||||||
| booleano | Opcional. Especifique se há uma restrição de exclusividade na chave de shard. Somente | ||||||||
| inteiro | Opcional. Especifica o número inicial de chunks para criar em todos os shards no cluster ao refragmentar uma collection. O valor padrão é Se você ver o erro "A chave de shard fornecida não tem cardinalidade suficiente para criar o número necessário de blocos", refaça a coleta com um valor A partir do MongoDB 8.2, as operações de refragmentação ignoram a configuração | ||||||||
| documento | Opcional. Se a coleção especificada em | ||||||||
| array | Opcional. Especifica as zonas da collection. Para manter ou adicionar zonas, especifique as zonas da sua collection em uma array: | ||||||||
| booleano | Opcional. Se definida como Novidades na versão 8.0. | ||||||||
| booleano | Opcional. Permite que as operações de refragmentação sejam concluídas rapidamente. Quando definido como true, |
Considerações
As compilações de índice que ocorrem durante a refragmentação podem falhar silenciosamente.
Não crie índices durante o processo de refragmentação.
Não inicie o processo de refragmentação se houver construções de índice em andamento.
Se a collection que você está refragmentando usar MongoDB Search, o índice de pesquisa ficará indisponível quando a operação de refragmentação for concluída. Você precisa refragmentar manualmente o índice de pesquisa assim que a operação de refragmentação for concluída.
Processo de refragmentação
Em uma operação de refragmentação de collection, um fragmento (shard) pode ser um:
doador, que atualmente armazena chunks para a coleção fragmentada.
receptor, que armazena novos chunks para a coleção fragmentada com base nas chaves de fragmento e nas zonas.
Um shard pode ser doador e um receptor ao mesmo tempo.
O servidor de configuração primário é sempre o gerenciador de refragmentação e inicia cada fase da operação de refragmentação.
Fase de inicialização
Durante a fase de inicialização, o coordenador de refragmentação determina a nova distribuição de dados para a collection fragmentada.
Fase de clone
Durante a fase de clonagem:
Cada shard destinatário cria uma coleção fragmentada temporária e vazia com as mesmas opções de coleção que a coleção fragmentada do doador. Essa nova coleção é o destino para onde os shards do destinatário gravam os novos dados. Os fragmentos do destinatário não criam nenhum índice, exceto o índice
_idaté a fase de índice.Cada shard do destinatário clona os dados de coleta do shard do doador, incluindo todos os documentos que o shard do destinatário possui sob a nova chave de shard.
Fase do índice
Durante a fase de índice, cada shard destinatário cria os novos índices necessários. Isso inclui todos os índices existentes na collection fragmentada e um índice compatível com o novo padrão de chave de shard, se esse índice ainda não existir na collection fragmentada.
Fase de aplicação e recuperação
Alterado na versão 8.2.
Durante a fase de aplicação e recuperação:
Cada shard de destinatário começa a aplicar entradas de oplog que foram gravadas no shard de doador correspondente depois que o destinatário clonou os dados.
Quando a estimativa do tempo restante para concluir a operação de refragmentação estiver abaixo de 500 ms, o shard do doador bloqueará as gravações na collection de origem.
Observação
Se desejar, você pode forçar manualmente a conclusão da operação de refragmentação emitindo o comando commitReshardCollection . Isso é útil se a estimativa de tempo atual para concluir a operação de refragmentação for uma duração aceitável para que sua collection bloqueie gravações. O comando commitReshardCollection bloqueia as gravações antecipadamente e força a conclusão da operação de refragmentação. Durante o período de bloqueio das gravações, seu aplicativo experimenta um aumento na latência.
Fase de confirmação
Durante a fase de confirmação:
O coordenador de refragmentação espera que todos os shards atinjam consistência estrita e, em seguida, confirma a operação de refragmentação.
O coordenador de refragmentação instrui cada primary shard doador e destinatário, de forma independente, a renomear a collection fragmentada temporária. A collection temporária torna-se a nova collection refragmentada.
Cada shard doador descarta a antiga coleção fragmentada.
Observação
Depois que o processo de refragmentação atingir a fase de confirmação, o processo não poderá ser encerrado abortReshardCollection com.
Exemplos
Refragmentar uma collection
O exemplo a seguir refragmenta a coleta sales.orders com a nova chave de fragmento { order_id: 1 }:
db.adminCommand({ reshardCollection: "sales.orders", key: { order_id: 1 } })
Saída:
{ ok: 1, '$clusterTime': { clusterTime: Timestamp(1, 1624887954), signature: { hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0), keyId: 0 } }, operationTime: Timestamp(1, 1624887947) }
Redistribuir dados para novos shards
A partir do MongoDB 8.0, você pode refragmentar uma collection na mesma chave, que pode ser usada para redistribuir dados em novos shards.
Após adicionar um shard ao cluster, você utiliza o comando reshardCollection com a opção forceRedistribution para redistribuir dados pelo cluster:
db.adminCommand({ reshardCollection: "accounts.invoices", key: { store_id: "hashed" }, forceRedistribution: true })
Redistribuir dados para diferentes zonas
A partir do MongoDB 8.0, você pode utilizar o comando reshardCollection para mover dados para novas zonas sem alterar a chave de shard.
O comando a seguir redistribui dados para a collection accounts.sales usando a mesma chave de shard, movendo dados para os shards associados às zonas zone04 e zone05:
db.adminCommand({ reshardCollection: "accounts.sales", key: { region_id: "hashed" }, forceRedistribution: true, zones: [ { zone: "zone04", min: { region_id: MinKey() }, max: { region_id: 10 } }, { zone: "zone05", min: { region_id: 10 }, max: { region_id: MaxKey() } } ] })