Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

sh.reshardCollection() (método mongosh)

sh.reshardCollection(namespace, key, unique, options)

The sh.reshardCollection() method changes the shard key for a collection and changes the distribution of your data.

Antes de refragmentar uma coleção, leia os requisitos de refragmentação e as limitações de refragmentação.

Importante

Método mongosh

This page documents a mongosh method. This is not the documentation for database commands or language-specific drivers, such as Node.js.

Para o comando do banco de dados, consulte o comando reshardCollection.

Para drivers de API do MongoDB, consulte a documentação do driver do MongoDB específica da linguagem.

sh.reshardCollection() usa os seguintes campos:

Campo
Tipo
Descrição

namespace

string

O namespace da collection para fragmentar no formato "<database>.<collection>".

key

documento

O documento que especifica o novo campo ou campos a serem usados como a chave de shard.

{ <field1>: <1|"hashed">, ... }

Defina os valores do campo como:

Consulte também Índices de chaves de shard

unique

booleano

Opcional. Especifique se há uma restrição de exclusividade na chave de shard. Somente false é suportado. O padrão é false.

unique: false não remove as restrições de exclusividade existentes. Um índice único que existe na coleção antes de você refragmentar permanece único após a conclusão da operação de refragmentação. A nova chave de shard com hash deve satisfazer os requisitos de índices únicos para quaisquer índices únicos existentes.

options

documento

opcional. Um documento contendo campos opcionais, incluindo numInitialChunks, numSamplesPerChunk, collation, zones e forceRedistribution.

O campo options suporta os seguintes campos:

Campo
Tipo
Descrição

numInitialChunks

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 é 90. Em seguida, o MongoDB cria e equilibra os chunks no cluster. numInitialChunks deve resultar em menos de 8192 por shard.

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 numInitialChunks menor.

As operações de refragmentação ignoram a configuração numInitialChunks quando a chave de fragmento contém um prefixo com hash. Em vez disso, o MongoDB divide deterministicamente o espaço de chave hasheada entre os destinatários, usando a mesma abordagem da criação inicial de partes para coleções vazias com hash.

numSamplesPerChunk

inteiro

opcional. Especifica o número de documentos a serem amostrados em novas partes. Por padrão, o MongoDB amostra 10 documentos em cada parte.

Novidades na versão 8.0.20.

collation

documento

Opcional. Se a coleção especificada para reshardCollection tiver um agrupamento padrão, você precisa incluir um documento de agrupamento com { locale : "simple" }, senão o comando reshardCollection falha.

zones

array

Opcional. Especifica as zonas da collection.

Para manter ou adicionar zonas, especifique as zonas da sua collection em uma array:

[
{s
min: <document with same shape as shardkey>,
max: <document with same shape as shardkey>,
zone: <string> | null
},
...
]

forceRedistribution

booleano

Opcional. Se definida como true, a operação será executada mesmo que a nova chave de shard seja igual à chave de shard antiga. Use com a opção zones para mover dados para zonas específicas.

Novidades na versão 8.0.

Esse método está disponível em implantações hospedadas nos seguintes ambientes:

  • MongoDB Atlas: The fully managed service for MongoDB deployments in the cloud

Importante

This command is not supported in M0 and Flex clusters. For more information, see Unsupported Commands.

  • 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

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.

  • If the collection uses Atlas Search, the search index becomes unavailable after the operation completes. To restore it, manually rebuild the search index.

  • Coleções que usam queryable encryption não são suportadas.

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.

Durante a fase de inicialização, o coordenador de refragmentação determina a nova distribuição de dados para a collection fragmentada.

Durante a fase de clonagem:

  1. 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 doadora. Os shards destinatários não criam nenhum índice, exceto _id, até a fase de índice.

  2. Cada shard receptor clona os dados da coleção dos shards doadores e grava os dados clonados em sua coleção temporária, que contém todos os documentos que o shard receptor possui sob a nova chave de shard com hash.

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.

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 necessário, você pode forçar manualmente a conclusão da operação de refragmentação emitindo o método sh.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 método sh.commitReshardCollection() bloqueia as gravações antecipadamente e força a conclusão da operação de refragmentação. Durante o período em que as gravações são bloqueadas, seu aplicativo experimenta um aumento na latência.

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 sh.abortReshardCollection() com.

O exemplo a seguir refragmenta a coleta sales.orders com a nova chave de fragmento { order_id: 1 }:

sh.reshardCollection( "sales.orders", { order_id: 1 } )

Saída de exemplo:

{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp(1, 1624887954),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: 0
}
},
operationTime: Timestamp(1, 1624887947)
}

In order to reshard to the same shard key, set forceRedistribution to true. The following example reshards the sales.orders collection to the same shard key { order_id: 1 } and redistributes data.

sh.reshardCollection(
"sales.orders",
{ order_id: 1 },
{ forceRedistribution: true }
)

Saída de exemplo:

{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp({ t: 1733502241, i: 20 }),
signature: {
hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
keyId: Long('0')
}
},
operationTime: Timestamp({ t: 1733502241, i: 20 })
}

Para obter detalhes, consulte Refragmentar uma collection de volta para a mesma chave de shard.

Refragmente uma collection com zonas quando precisar ajustar a distribuição de dados entre os shards em seu cluster para atender aos requisitos de alteração ou para melhorar o desempenho.

No exemplo a seguir , a coleção test.scores reside em shard0 e shard1. A chave de fragmento atual é { _id: 1}.

1

Neste exemplo, essa zona é chamada NewZone.

sh.addShardToZone( "shard2", "NewZone" )
sh.addShardToZone( "shard3", "NewZone" )
2
sh.reshardCollection(
"test.scores",
{ "studentId": 1, "testId": 1},
{ zones: [ {
min: { "studentId": MinKey(), "testId": MinKey() },
max: { "studentId": MaxKey(), "testId": MaxKey() },
zone: "NewZone" }
]
} )

A operação de refragmentação adiciona os shards na zona NewZone como destinatários. O fragmento primário do banco de dados de dados é adicionado como um destinatário como um backstop para quaisquer intervalos ausentes na definição da zona . Se não houver intervalos ausentes, a coleção será clonada em fragmentos no "NewZone", como shard2 e shard3 neste exemplo. sh.reshardCollection retorna o seguinte:

{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp( { t: 1699484530, i: 54 } ),
signature: {
hash: Binary.createFromBase64( "90ApBDrSSi4XnCpV3OWIH4OGO0Y=", 0 ),
keyId: Long( "7296989036055363606" )
} },
operationTime: Timestamp( { t: 1699484530, i: 54 } )
}