Menu Docs
Página inicial do Docs
/
Manual do banco de dados
/ /

Refragmentar uma coleção de volta para a mesma chave de fragmento

A refragmentação para a mesma chave de shard permite usar a refragmentação como um mecanismo de movimentação de dados. Isso permite que você:

  • Use a técnica Reshard to Shard para fragmentar uma coleção e distribuir seus dados em todos os fragmentos relevantes

  • Adicionar novos shards mais rapidamente

  • Remova fragmentos com mais rapidez

  • Reescreva coleções para recuperar espaço em disco

A operação de refragmentação executa estas fases na ordem:

  1. A fase do clonagem duplica os dados da collection atual.

  2. A fase de construção de índices cria índices na collection refragmentada.

  3. A fase de atualização aplica quaisquer operações de gravação pendentes à collection refragmentada.

  4. A fase de confirmação renomeia a collection temporária e descarta a collection antiga para executar um cutover.

Antes de fazer a refragmentação, você deve calcular os Requisitos de armazenamento, Requisitos de latência e quaisquer Requisitos de recursos adicionais.

Calcule o espaço de armazenamento necessário para a operação de refragmentação adicionando o tamanho da collection e o tamanho do índice, presumindo uma oplog window mínima de 24 horas usando esta fórmula:

Available storage required on each shard = [(collection size + index size) *2 ] / number of shards the collection will be distributed across.

Por exemplo, uma collection de 2TB e 400GB de índices distribuídos em 4 fragmentos precisará de um mínimo de 1.2TB de armazenamento disponível por fragmento:

[ (2 TB + 400GB) * 2 ] / 4 shards = 1.2 TB / shard

Você deve confirmar que tem o espaço de armazenamento disponível no seu cluster.

Se não houver espaço suficiente ou espaço de E/S disponível, você deverá aumentar o tamanho do armazenamento. Se não houver espaço suficiente para a CPU, você deverá escalar o cluster selecionando um tamanho de instância maior.

Dica

Se o MongoDB cluster estiver hospedado no Atlas, você poderá usar a UI do Atlas para analisar as métricas de armazenamento, CPU e espaço de E/S.

Você deve garantir que seu aplicação possa tolerar dois segundos em que a collection que está sendo refragmentada bloqueia as gravações. Quando as gravações são bloqueadas, seu aplicação experimenta um aumento na latência. Se seu volume de trabalho não tolerar esse requisito, use migrações de chunks para equilibrar o cluster.

Seu cluster deve atender a estes requisitos adicionais:

  • Uma oplog window mínima de 24 horas.

  • Capacidade de E/S abaixo de 50%.

  • Carga da CPU abaixo de 80%.

1

Utilize o comando reshardCollection com a opção forceRedistribution definida como true para refragmentar a coleção. O comando reshardCollection 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>
}
)

Por exemplo, este comando refragmenta a collection info.productsInformation em sua chave de shard atual { product_SKU : 1 }:

db.adminCommand(
{
reshardCollection: "info.productsInformation",
key: { product_SKU : 1 },
forceRedistribution: true
}
)

Observação

A partir do MongoDB 8.2, as operações de refragmentação ignoram a configuração numInitialChunks quando a chave de shard 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 chunks para collections vazias com hash.

2

Para monitorar a operação de refragmentação, você pode usar o estágio de pipeline$currentOp:

db.getSiblingDB("admin").aggregate(
[
{ $currentOp: { allUsers: true, localOps: false } },
{
$match: {
type: "op",
"originatingCommand.reshardCollection": "<database>.<collection>"
}
}
]
)

Observação

Para ver os valores atualizados, você precisa executar continuamente o pipeline.

As saídas do pipeline $currentOp:

  • totalOperationTimeElapsedSecs: tempo de operação decorrido em segundos

  • remainingOperationTimeEstimatedSecs: tempo restante estimado em segundos para a operação de refragmentação atual. É retornado como -1 quando uma nova operação de refragmentação é iniciada.

    A partir do MongoDB 7.0, remainingOperationTimeEstimatedSecs também está disponível no coordenador durante uma operação de refragmentação.

    remainingOperationTimeEstimatedSecs está definido para uma estimativa de tempo pessimista:

    • A estimativa de tempo da fase de recuperação é definida como o tempo da fase de clonagem, que é um tempo relativamente longo.

    • Na prática, se houver apenas algumas operações de escrita pendentes, o tempo de fase de recuperação real é relativamente curto.

[
{
shard: '<shard>',
type: 'op',
desc: 'ReshardingRecipientService | ReshardingDonorService | ReshardingCoordinatorService <reshardingUUID>',
op: 'command',
ns: '<database>.<collection>',
originatingCommand: {
reshardCollection: '<database>.<collection>',
key: <shardkey>,
unique: <boolean>,
collation: { locale: 'simple' }
},
totalOperationTimeElapsedSecs: <number>,
remainingOperationTimeEstimatedSecs: <number>,
...
},
...
]

Voltar

Refragmentar para a mesma chave de fragmento