Otimize a migração de dados no MongoDB: técnicas de resharding para velocidade e escalabilidade

Precisa fragmentar uma coleção de 2 TB e distribuir os dados em todos os seus fragmentos em menos de 24 horas? Aproveite o resharding para acelerar sua migração de dados!

Nesta postagem, abordaremos uma técnica chamada “reshard-to-shard” que usa resharding para espalhar dados entre os shards em seu cluster rapidamente.

Iremos abordar:

1. Considerações antes e durante a migração.
2. Como iniciar, monitorar e abortar a migração de dados mais rápida.

Se você é novo em sharding ou deseja se atualizar sobre como o MongoDB oferece escalabilidade horizontal, confira o Manual do MongoDB .

Índice

• Fundo
• Quais são os benefícios do reshard-to-shard?
• Quando devo usar reshard-to-shard?
• Quando não devo usar reshard-to-shard?
• Quais são os pré-requisitos de reshard-to-shard?
• Visão geral da técnica de reshard-to-shard
• Exemplo de reshard-to-shard
• perguntas frequentes

Fundo

Quando uma coleção é inicialmente fragmentada em um cluster de vários fragmentos, o balanceador começa a migrar dados do fragmento que contém a coleção fragmentada recentemente para os outros fragmentos no cluster para distribuir igualmente a coleção entre os fragmentos. Quando o balanceador está migrando dados, um estilhaço só pode participar de uma migração por vez, independentemente de quantas coleções precisam ser migradas. O que significa que em um cluster de 3 estilhaços, apenas dois estilhaços por vez podem migrar dados entre eles. Resharding não compartilha as mesmas limitações por causa das diferenças internas de execução.

Como resharding é reescrever todos os dados, ele é capaz de gravar dados em paralelo em todos os estilhaços do cluster, aumentando a taxa de transferência e reduzindo consideravelmente o tempo de migração de dados entre os estilhaços em relação ao que o balanceador pode realizar. Resharding cria uma nova coleção com uma nova chave de estilhaço em segundo plano em cada um dos estilhaços, mantendo sua coleção existente disponível para seu aplicativo utilizar. Depois que todos os documentos forem clonados na nova coleção, ocorrerá a substituição. A coleção existente com a chave de estilhaço antiga é descartada em favor da nova coleção criada pela operação de reestilhaçamento.

Quais são os benefícios do reshard-to-shard?

Primeiro, é muito mais rápido! Aproveitando o resharding, um cliente conseguiu fragmentar e distribuir sua coleção de 3,5 TB em quatro fragmentos em 22,5 horas. O mesmo processo levaria 30 dias se deixado para o método padrão do balanceador de migrações de partes.

Em segundo lugar, afeta minimamente sua carga de trabalho! Após o balanceador migrar os dados, ele deve conduzir uma operação de limpeza chamada exclusão de intervalo no estilhaço que doou os dados, pois apenas um estilhaço pode possuir cada documento específico. A exclusão de intervalo é uma operação intensiva de E/S que pode afetar o desempenho do cluster. O resharding não precisa conduzir a exclusão de intervalo, pois ele descarta a coleção antiga depois de passar para a nova coleção com a nova chave de fragmentação.

Em terceiro lugar, você recupera automaticamente seu espaço em disco! Ao descartar a coleção antiga, ele libera espaço de armazenamento para ser usado por qualquer coleção sem a necessidade de executar uma operação como compactar . Isso significa que você pode reduzir o armazenamento de forma mais rápida e fácil após a operação, se desejar.

Por exemplo, um cliente estava consumindo quase 2,8 TB em shard0 antes que a operação de resharding de sua maior coleção fosse concluída.

Quando o resharding foi concluído, 1,9 TB de espaço de armazenamento foi devolvido imediatamente! Eles passaram de consumir 2,7 TB de armazenamento para 873 GB de armazenamento.

Quando devo usar reshard-to-shard?

Resposta: Quando você está inicialmente fragmentando uma coleção de qualquer tamanho em qualquer número de fragmentos.

Existem alguns cenários em que o balanceamento pode ser mais rápido (por exemplo, menos de 100 GB), mas você ainda deve levar em consideração a exclusão de intervalo e a recuperação do armazenamento por meio de sincronização compacta ou inicial. Portanto, se você tiver capacidade, recomendamos reshard-to-shard, independentemente do tamanho da coleção que deseja fragmentar.

Quando não devo usar reshard-to-shard?

Você não deve usar a tática reshard-to-shard quando:

• Seu aplicativo não pode tolerar um bloqueio de gravações por dois segundos para permitir a transição para a coleção refragmentada.

  • A duração das gravações pode ser bloqueada para a coleção sendo resharded por padrão é de dois segundos, há um parâmetro configurável que pode modificar a duração do bloqueio.

    
    

• Sua coleção é uma coleção de séries temporais
  • Se você tentar fragmentar novamente uma coleção de séries temporais, receberá uma mensagem de erro informando que não há suporte para a fragmentação de uma coleção de séries temporais.

Para os cenários listados acima, use o método tradicional de fragmentação de uma coleção e deixe o balanceador migrar os dados.

Quais são os pré-requisitos de reshard-to-shard?

1. Um cluster MongoDB executando o MongoDB 5.0 ou superior
2. Você deve selecionar uma chave de fragmentação apropriada para sua coleção.
3. Crie os índices necessários para dar suporte à chave de fragmentação temporária e à chave de fragmentação desejada.
4. Além disso, como você usará resharding para acelerar as velocidades de migração de dados, familiarize-se com o requisitos e limitações de resharding .

Para executar com êxito uma operação de resharding, seu cluster deve ter:

• 1,2x o tamanho da coleção por estilhaço disponível em cada estilhaço.
  • Por exemplo, se você estiver fragmentando uma coleção de 1 TB em 4 estilhaços, o tamanho da coleção fragmentada será de 250 GB por estilhaço quando distribuído em 4 estilhaços. Você deseja ter um mínimo de 300 GB de armazenamento disponível em cada estilhaço.
• Capacidade de E/S abaixo de 50%
• Uso da CPU abaixo de 80%

Os clientes que usam o Atlas cujo cluster não atende aos requisitos de armazenamento, E/S e CPU para executar o resharding podem facilmente escalar seu cluster e/ou personalizar o armazenamento para aumentar os recursos do cluster para permitir uma operação de resharding bem-sucedida. Eles podem voltar ao normal assim que a operação for concluída.

Visão geral da técnica de reshard-to-shard

Há duas etapas muito simples para executar uma operação reshard-to-shard:

1. Shard em uma chave de fragmento temporária
2. Reshard em sua chave de fragmento desejada

Por que eu fragmentaria primeiro em uma chave de fragmentação temporária e isso não prejudicaria meu aplicativo?

Vamos explicar!

Passo um: shard com uma chave de shard temporária

Atualmente, o resharding não oferece suporte ao resharding na mesma chave de fragmentação (ele funcionará como um "não operacional" porque você já está no estado desejado). Para contornar essa limitação, a técnica reshard-to-shard requer a fragmentação intencional em uma chave de fragmentação temporária diferente da chave de fragmentação desejada. Devido ao suporte do MongoDB para sharding de intervalo e sharding de hash, a chave de shard temporária pode ser ligeiramente modificada da chave de shard desejada que você selecionou para sua coleção.

A chave de fragmentação temporária deve selecionar uma estratégia de particionamento diferente para apenas um de seus campos de chave de fragmentação. Devido às limitações de determinadas consultas, como updateOne(), updateMany(), deleteOne(), etc., que exigem que a consulta inclua a chave de fragmentação, você usará uma estratégia de particionamento diferente. O MongoDB usa estratégias de particionamento apenas como uma forma de determinar como distribuir seus dados pelos shards em seu cluster e não altera os valores no documento. Isso significa que seu aplicativo pode utilizar um updateOne ou outra consulta que requer a chave de estilhaço com ambas as estratégias de particionamento.

Por exemplo, se a chave de fragmentação desejada que você selecionou para sua coleção for:

 {"_id": "hashed"}

A chave de fragmentação temporária a ser usada inicialmente para sua coleção deve ser:

 {"_id": 1}

Para chaves de fragmentação compostas, apenas um de seus campos de chave de fragmentação precisa usar uma estratégia de particionamento diferente. Por exemplo, se a chave de fragmentação desejada que você selecionou para sua coleção for:

 { launch_vehicle: 1, payload: 1}

Sua chave de fragmentação temporária deve ser:

 { launch_vehicle: 1, payload: "hashed"}

A tática reshard-to-shard exige um resharding imediato na chave de fragmentação que você usará a longo prazo após a conclusão da fragmentação inicial da coleção com a chave de fragmentação temporária. Isso mantém mais de 99% dos dados em um fragmento enquanto a operação de resharding é executada, reduzindo significativamente o impacto das consultas de transmissão.

Se quiser garantir que 100% dos seus dados estejam em um fragmento, você pode desativar o balanceador antes de inicialmente fragmentar a coleção com a chave temporária do fragmento. Desabilitar o balanceador garante que nenhuma migração ocorra antes que o resharding seja iniciado. Abordaremos como você pode desligar o balanceador no exemplo abaixo.

Uma vez que você terá construído ambos os índices para sua chave de fragmentação temporária e desejada, enquanto a operação de resharding está sendo conduzida, as consultas que utilizam sua chave de fragmentação desejada terão bom desempenho, pois podem alavancar o índice para a chave de fragmentação desejada enquanto sua coleção é particionada temporariamente pela sua chave de fragmentação temporária.

Passo dois: reshard em sua chave de fragmento desejada

A segunda etapa é executar uma operação de resharding normal, exceto que você está aproveitando um efeito colateral de como o resharding funciona em seu benefício.

O resharding tem quatro fases principais:

• Inicialização - a coleção que está passando por resharding é amostrada e uma nova distribuição de dados com base na nova chave de shard é determinada.

  
  

• Índice - a operação de reestilhaçamento cria uma nova coleção estilhaçada temporária vazia em todos os estilhaços com base na nova chave de estilhaço e cria os índices, incluindo os índices de chaves não estilhaçadas que suportam a coleção existente.

  
  

• Clone, Catch-Up e Apply - os documentos são clonados para os estilhaços de acordo com a nova chave de estilhaço e quaisquer modificações nos documentos enquanto a operação de resharding foi executada são aplicadas.

  
  

• Confirmar - a coleção temporária é renomeada e ocupa o lugar da coleção que está sendo fragmentada novamente e a coleção agora antiga é descartada.

Depois de revisar as fases acima, você pode ver como obterá o benefício da movimentação rápida de dados, uma coleção fragmentada que é distribuída igualmente entre seus fragmentos assim que a operação for concluída e espaço de armazenamento liberado de uma só vez.

Após a conclusão da operação de resharding, você pode realizar operações de limpeza, como descartar o índice de chave de fragmento temporário e reduzir o cluster e/ou o armazenamento para atender às suas necessidades de estado estável.

Exemplo de reshard-to-shard

Digamos que você esteja trabalhando em um aplicativo que rastreará aeronaves comerciais para que os clientes possam ser notificados se for provável que seu voo atrase. Você estudou os padrões de consulta do seu aplicativo e revisou quais atributos contribuem para uma boa chave de fragmentação.

A chave de fragmentação que você selecionou para sua coleção é:

 { airline: 1, flight_number: 1, date: "hashed" }

Com a chave de estilhaço determinada, você pode começar a verificar os pré-requisitos para executar uma operação de reshard-to-shard. Primeiro, você gera sua chave de fragmentação temporária. Conforme declarado anteriormente, você deseja que sua chave de fragmento temporária seja uma versão levemente modificada da chave de fragmento desejada.

Portanto, a chave de fragmentação temporária que você selecionou é:

 { airline: 1, flight_number: 1, date: 1}

Em seguida, você cria os índices para dar suporte às chaves de fragmentação temporárias e finais.

Os índices podem ser criados usando o shell Mongo por meio do comando db.collection.createIndexes() :

 db.flight_tracker.createIndexes([ {"airline": 1, "flight_number": 1, date: "hashed"}, {"airline": 1, "flight_number": 1, date: 1} ])

As compilações de índice podem ser monitoradas usando mongo shell por meio do seguinte comando:

 db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] })

Se você quiser garantir que nenhuma migração ocorra entre a fragmentação de sua coleção e quando a nova fragmentação for invocada, você pode desativar o balanceador executando o seguinte comando:

 sh.stopBalancer()

Se o seu cluster MongoDB for implantado no Atlas, você poderá usar a IU do Atlas para revisar facilmente as métricas disponíveis que informam que seu cluster tem armazenamento livre suficiente disponível, além da CPU e espaço de E/S para conduzir uma operação de resharding.

Se não houver espaço de armazenamento suficiente disponível ou headroom de E/S, você poderá dimensionar o armazenamento. Por falta de espaço na CPU, você pode dimensionar o cluster. O dimensionamento do armazenamento e do cluster é feito facilmente por meio da IU do Atlas.

Acessar a configuração do cluster é simples e pode ser feito na tela de visão geral do seu grupo, que exibe todos os clusters implantados para o grupo.

Com todos os pré-requisitos atendidos, você pode iniciar a primeira parte do processo de reshard-to-shard - fragmentando a coleção com a chave de fragmentação temporária.

Você pode usar o shell do Mongo e o comando sh.shardCollection() para fragmentar a coleção:

 sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: 1} )

sh.shardCollection() retornará um documento quando concluído, o campo ok terá valor 1 se a operação for bem-sucedida.

 { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) }

Assim que a coleção for fragmentada, você poderá imediatamente reestilhaçar a coleção!

Para reshard sua coleção na chave de fragmento desejada, use sh.reshardCollection() no shell mongo:

 sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" })

Se você executar o comando sh.status() no shell mongo, verá uma nova coleção na saída com o formato do nome da nova coleção sendo <db_name>.system.resharding.<UUID> . Esta é a coleção que o resharding está construindo e distribuindo os dados de acordo com a chave de fragmentação desejada

Para monitorar o status da operação de resharding para a coleção flight_tracker, você pode usar o seguinte comando

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

A saída do comando informará em qual estágio a operação de resharding está sendo executada no momento e o tempo estimado para conclusão por meio do campo restanteOperationTimeEstimatedSecs. Observe que o tempo estimado para a conclusão do novo compartilhamento é pessimista e as operações de novo compartilhamento levam muito menos tempo do que o relatado!

A operação de refragmentação deve estar quase concluída quando o tamanho dos dados de cada estilhaço tiver aumentado pelo tamanho da coleção que está sendo reestilhaçada dividido pelo número de estilhaços no cluster. Por exemplo, uma coleção de 1 TB sendo refragmentada em 4 estilhaços, a operação de reestilhaçamento deve ser concluída quando cada estilhaço tiver gravado 250 GB (sem contabilizar outros dados sendo inseridos, atualizados ou excluídos no estilhaço).

Se o seu cluster for implantado no Atlas, você também poderá monitorar o progresso da operação de resharding por meio da IU do Atlas usando a guia Métricas do cluster.

• Para clusters Atlas executando MongoDB 6.0 e superior - você pode usar a opção de exibição de tamanho de dados do shard e, em seguida, selecionar uma coleção com uma sintaxe de <db_name>.system.resharding.<UUID> . Essa exibição isola a coleção temporária e exibirá apenas o crescimento do tamanho dos dados da nova coleção.

  
  

• Para clusters Atlas executando MongoDB 5.0 - você pode usar a opção de exibição de tamanho de dados lógicos db. Essa exibição não permite o isolamento no nível da coleção.

  
  

Enquanto o resharding está em execução, as três métricas do cluster que você deve monitorar principalmente são:

• Armazenamento disponível - consumir todo o armazenamento disponível pode levar à instabilidade do cluster
• Utilização da CPU - a alta utilização da CPU pode levar à degradação do desempenho do cluster
• Uso de E/S - o uso de E/S acima de sua capacidade pode levar à degradação do desempenho do cluster

Se você estiver preocupado com o fato de o resharding afetar negativamente seu cluster, você pode interromper instantaneamente a operação de resharding antes que ela atinja a parte de confirmação do processo por meio do seguinte comando:

 sh.abortReshardCollection("main.flight_tracker")

Se você desligou o balanceador para garantir que nenhuma migração ocorra entre a fragmentação e a nova fragmentação da coleção, ative o balanceador novamente usando o seguinte comando:

 sh.startBalancer()

A operação de resharding ao concluir retornará se a operação foi bem-sucedida ou não para o cliente que a invocou.

Como o resharding é uma operação de longa duração e você pode ter fechado a sessão de shell do Mongo, verifique se a operação de fragmentação ainda está em execução usando a agregação de monitoramento de resharding se desejar detalhes ou sh.status() para ver se a coleção temporária ainda está presente na saída. Se a agregação de resharding não retornar nada ou se você não vir mais uma coleção temporária na saída de sh.status(), a operação de resharding foi encerrada.

Você pode usar db.collection.getShardDistribution para verificar se a operação foi bem-sucedida:

 db.flight_tracker.getShardDistribution()

Se o resharding for concluído com êxito, você verá uma saída em que a distribuição é igual entre os estilhaços.

• Para o MongoDB 6.0 e maior, a uniformidade é determinada pelo tamanho dos dados por estilhaço, portanto, você deve ver uma quantidade quase igual de dados em cada um dos estilhaços na saída de db.collection.getShardDistribution.

  
  

• Para o MongoDB 5.0, a uniformidade é determinada pelo número de fragmentos por fragmento, portanto, você deve ver um número igual de fragmentos em cada um dos fragmentos na saída de db.collection.getShardDistribution.

Se o seu cluster for implantado no Atlas, você poderá usar a IU do Atlas por meio da guia Métricas para determinar se a operação de resharding foi bem-sucedida.

• Para clusters Atlas executando MongoDB 6.0 e superior - você pode usar a opção de exibição de tamanho de dados de fragmentos e, em seguida, selecionar sua coleção que passou por resharding. Você deve ver uma quantidade igual de dados por estilhaço exibido.

  
  

• Para clusters Atlas executando o MongoDB 5.0 - você pode usar a opção de exibição de blocos e, em seguida, selecionar sua coleção que passou por resharding. Você deve ver um número quase igual de pedaços exibidos em todos os estilhaços em seu cluster.

  
  

Tanto para o tamanho dos dados do fragmento quanto para o número de fragmentos, a IU do Atlas exibirá um aumento acentuado na métrica relevante devido ao resharding usando um formato de nome de coleção de <db_name>.system.resharding.<UUID> temporariamente antes de renomeá-lo e descartar o antigo coleção com a chave de fragmento antiga.

Se o resharding for interrompido, a saída de db.collection.getShardDistribution provavelmente mostrará a maioria dos dados no shard no qual a coleção foi inicialmente fragmentada. Abortagens com resharding são raras e prováveis porque o resharding não pôde conduzir o cutover da coleta em 2 segundos ou menos.

Se for esse o caso, recomendamos cronometrar o início do resharding para que ele tente confirmar durante um período de menor tráfego para seu cluster. Como alternativa, se seu aplicativo puder tolerar um bloqueio de gravações por mais de 2 segundos, você poderá modificar o tempo de confirmação aumentando a duração com o parâmetro reshardingCriticalSectionTimeoutMillis além do padrão de 2000ms.

Depois que a operação de resharding estiver concluída, você poderá realizar operações de limpeza, como descartar o índice de chave de fragmento temporário e reduzir seu cluster e/ou seu armazenamento para atender às suas necessidades de estado estável.

Agora você pode descartar o índice temporário com o comando db.collection.dropIndex() no shell mongo!

 db.flight_tracker.dropIndex( {"airline": 1, "flight_number": 1, "date": 1} )

perguntas frequentes

1. Quanto tempo leva o reshard-to-shard?

   
   

   • Depende do tamanho da sua coleção, do número e tamanho dos índices da sua coleção e do número de estilhaços em seu cluster, mas estamos confiantes de que você pode fragmentar novamente uma coleção de 4 TB com 10 índices em 4 estilhaços em 48 horas ou menos. Deixar o balanceador lidar com as migrações levaria 30 dias ou mais.

     
     

2. Por que o resharding é mais rápido do que permitir que o balanceador migre os dados?

   
   

   • Os aspectos internos de como o balanceador e o resharding migram os dados são diferentes. O resharding lê os documentos em uma ordem diferente das migrações de fragmentos e, como o resharding é concluído com a eliminação da coleção antiga, não há espera pela exclusão do intervalo para liberar o espaço em disco.

     
     

3. Eu quero usar reshard-to-shard em uma coleção que tem uma restrição de exclusividade e os índices de hash não suportam a imposição de exclusividade.

   
   

   • Se sua coleção tiver uma restrição de exclusividade, você poderá usar reshard-to-shard, mas terá que adotar uma abordagem diferente. Ao adicionar um campo adicional à sua chave de fragmentação temporária em vez de alterar a estratégia de particionamento, você desbloqueia a capacidade de reestilhaçar na chave de fragmentação desejada. Por exemplo, se a chave de fragmentação desejada for:

     
     

      { launch_vehicle: 1, payload: 1}

     
     

   • Sua chave de fragmentação temporária seria:

      { launch_vehicle: 1, payload: 1, launch_pad: 1}

     
     

   • Esteja ciente das limitações para consultas (ex: updateOne(), updateMany(), deleteOne()) que exigem que a consulta inclua a chave de fragmentação. Seu aplicativo deve incluir a chave de fragmentação temporária em todos os cenários em que uma consulta exige que a chave de fragmentação seja executada com êxito até que a operação de resharding seja concluída.

   
   

4. Como faço para monitorar uma operação de resharding em andamento?

   
   

   • Execute o seguinte comando:

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

6. Como faço para interromper uma operação de resharding em andamento?

   
   

   • Execute o seguinte comando, que aborta instantaneamente a operação de resharding:

      sh.abortReshardCollection("<database>.<collection>")

7. Estou preocupado com o resharding afetando o desempenho do meu cluster.

   
   

   • Se você atender aos requisitos de resharding descritos anteriormente, a operação não deve afetar o desempenho do cluster. No entanto, se o cluster estiver implantado no Atlas, você poderá dimensioná-lo temporariamente durante a execução de uma operação de reshard-to-shard e dimensionar o cluster novamente após a conclusão da operação.

     
     

8. Quais métricas do meu cluster devo monitorar enquanto a operação de resharding está em execução?

   
   

   • Espaço de armazenamento disponível - se algum dos seus fragmentos tiver menos de 100 GB de armazenamento disponível, você deve abortar o resharding

   • Utilização da CPU - se o seu cluster estiver consumindo todos os recursos de computação disponíveis, você pode causar contenção de recursos e deve interromper o resharding

   • Consumo de E/S - se o seu cluster estiver consumindo todas as IOPS disponíveis, você poderá causar contenção de recursos e deverá interromper o resharding.

     
     

9. A coleção temporária é aparentemente distribuída uniformemente em todos os meus estilhaços, por que o resharding não está completo?

   
   

   • Antes que o resharding possa passar para a coleção com a chave de fragmentação desejada, ela deve alcançar com todas as gravações que ocorreram desde que o resharding foi iniciado. Se sua carga de trabalho de gravação for pesada, pode levar um longo período de tempo para a conclusão da fase de recuperação.

     
     

10. Meu aplicativo não pode suportar gravações sendo bloqueadas por mais de 1 segundo, posso modificar a duração das gravações serão bloqueadas para a coleção que está sendo resharded?

    
    

    • Sim, mas não esperamos que essa opção seja utilizada com frequência, pois a operação de resharding, por padrão, tentará mudar para a nova coleção quando estimar que a transição pode ser realizada em menos de 1 segundo. Se seu aplicativo não puder suportar gravações sendo bloqueadas na coleção sendo fragmentada novamente por 2 segundos, você poderá modificar o parâmetro reshardingCriticalSectionTimeoutMillis para bloquear gravações por apenas 1 segundo.

      • Esteja ciente de que a redução desse valor aumenta a probabilidade de que a operação de resharding seja abortada, pois reduz o tempo limite que a operação de resharding pode esperar até que a seção crítica conclua o cutover.

    • Execute o seguinte comando:

       db.adminCommand({ setParameter: 1, reshardingCriticalSectionTimeoutMillis: 1000 })