Refragmentação para adicionar e remover fragmentos

Sobre esta tarefa

Você pode usar a refragmentação para distribuir suas collections fragmentadas para novos shards. Você também pode usá-lo para remover fragmentos mais rápido do que migrações de blocos.

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

A fase do clonagem duplica os dados da collection atual.
A fase de construção de índices cria índices na collection refragmentada.
A fase de atualização aplica quaisquer operações de gravação pendentes à collection refragmentada.
A fase de confirmação renomeia a collection temporária e descarta a collection antiga para executar um cutover.

Antes de começar

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

Requisitos de armazenamento

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.

Requisitos de latência

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.

Requisitos de recursos adicionais

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%.

Passos

Adicione ou remova fragmentos ao seu cluster.

Para adicionar shards ao seu cluster, consulte Adicionar shards a um cluster. Para remover fragmentos do seu cluster, consulte Remover fragmentos de um cluster fragmentado.

Refragmente as coleções fragmentadas, uma de cada vez, para a mesma chave de fragmento.

Utilize o comando reshardCollection com a opção forceRedistribution para redistribuir dados pelo cluster.

db.adminCommand(
   {
      reshardCollection: "<db>.<collection>",
      key: { "<shardkey>" },
      forceRedistribution: true
   }
)

A refragmentação com forceRedistribution: true reescreve os dados em todos os shards no cluster que não estão em um estado de drenagem . Por padrão, a refragmentação usa numInitialChunks: 90. A refragmentação cria pelo menos numInitialChunks - 1 blocos em um cluster. Se você tiver mais de 90 shards, especifique um número maior de numInitialChunks no comando reshardCollection.

Monitore a operação de refragmentação.

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>,
    ...
  },
  ...
]

A refragmentação com forceRedistribution: true reescreve os dados da collection em todos os shards relevantes e descarta a collection antiga. É o método mais rápido para mover dados em um cluster.

Saiba mais

Voltar

Refragmentar uma collection de volta para a mesma chave de shard

Referência