Menu Docs

Página inicial do DocsDesenvolver aplicaçõesManual do MongoDB

Gerenciar balancer de cluster fragmentado

Nesta página

  • Verifique o estado do balancer
  • Verifique se o balanceador está em execução
  • Configurar tamanho do intervalo padrão
  • Agendamento da janela de balanceamento
  • Remoção de um agendamento de janela de balanceamento
  • Desabilitar o balancer
  • Habilite o balanceador
  • Desativação do balanceamento durante backups
  • Desativação do balanceamento em uma collection
  • Como habilitar o balanceamento em uma coleção
  • Verifique se o equilíbrio está ativado ou desativado
  • Alteração do comportamento de replicação para migração de partes
  • Altere o tamanho máximo do armazenamento der um determinado shard

Alterado na versão 6.1.

Esta página descreve os procedimentos administrativos comuns relacionados ao equilíbrio. Para obter uma introdução ao balanceamento, consulte Sharded Cluster Balancer. Para obter informações de nível inferior sobre balanceamento, consulte Balancer Internals.

O processo do balanceador foi movido das instâncias mongos para o primário do conjunto de réplicas do servidor de configuração.

sh.getBalancerState() verifica se o balancer está habilitado (ou seja, se o balancer tem permissão para ser executado). sh.getBalancerState() não verifica se o balancer está migrando dados ativamente.

Para ver se o balanceador está ativado em seu cluster fragmentado, execute o seguinte comando, que retorna um booleano:

sh.getBalancerState()

Você também pode ver se o balanceador está ativado usando sh.status(). O campo currently-enabled indica se o balanceador está habilitado e o campo currently-running indica se o balanceador está atualmente em execução.

Para ver se o processo do balanceador está ativo em seu agrupamento:

  1. Conecte-se a qualquer mongos no cluster usando o shell mongosh .

  2. Utilize a seguinte operação para determinar se o balanceador está executando:

    sh.isBalancerRunning()

O tamanho do intervalo padrão de um cluster fragmentado é de 128 megabytes. Na maioria das situações, o tamanho padrão é apropriado para dividir e migrar blocos. Para informações sobre como o tamanho do intervalo afeta as implantações, consulte detalhes, consulte Tamanho do intervalo.

A alteração do tamanho do intervalo padrão afeta os intervalos que forem processos durante as migrações e as divisões automáticas, mas não afeta todos os intervalos de forma retroativa.

A partir do MongoDB 6.0.3, a divisão automática de chunks não é executada. Isso se deve às melhorias no balanceamento das políticas. Os comandos de divisão automática ainda existem, mas não executam uma operação.

Para configurar o tamanho padrão da faixa, consulte Modificar o tamanho da faixa em um cluster fragmentado.

Em algumas situações, especialmente quando o conjunto de dados cresce lentamente e uma migração pode afetar o desempenho, é útil garantir que o balanceador esteja ativo apenas em determinados momentos. O procedimento a seguir especifica o activeWindow, que é o período durante o qual o balanceador poderá migrar os blocos:

1

Você pode se conectar a qualquer mongos no cluster.

2

Dê o seguinte comando para passar para o banco de dados de configuração.

use config
3

O balanceador não será ativado no estado stopped. Para garantir que o balanceador não seja stopped, utilize sh.startBalancer(), como no seguinte:

sh.startBalancer()

O balanceador não será iniciado se você estiver fora do período da activeWindow.

A partir do MongoDB 6.0.3, a divisão automática de chunks não é executada. Isso se deve às melhorias no balanceamento das políticas. Os comandos de divisão automática ainda existem, mas não executam uma operação.

Nas versões MongoDB anteriores a 6.0.3, o sh.startBalancer() também habilita a divisão automática para o cluster fragmentado.

4

Configure o activeWindow utilizando updateOne(), como no seguinte:

db.settings.updateOne(
{ _id: "balancer" },
{ $set: { activeWindow : { start : "<start-time>", stop : "<stop-time>" } } },
{ upsert: true }
)

Substitua <start-time> e <end-time> por valores de tempo usando valores de hora e minuto de dois dígitos (ou seja, HH:MM) que especificam os limites inicial e final da janela de balanceamento.

  • Para valores de HH, utilize valores na faixa de hora variando de 00 a 23.

  • Para o valor MM, use valores de minuto que variam de 00 a 59.

Para clusters fragmentados locais ou autogerenciados, o MongoDB avalia os horários de início e parada em relação ao fuso horário do membro primário no conjunto de réplicas do servidor de configuração.

Para o Atlas cluster, o MongoDB avalia os horários de início e parada em relação ao fuso horário UTC.

Observação

A janela do balanceador deve ser suficiente para concluir a migração de todos os dados inseridos durante o dia.

Como as taxas de inserção de dados podem mudar de acordo com os padrões de atividade e uso, é importante garantir que a janela de balanceamento selecionada seja suficiente para dar suporte às necessidades de sua implantação.

Se você definiu a janela de balanceamento e deseja remover o agendamento para que o balanceador esteja sempre em execução, use $unset para limpar o activeWindow, conforme mostrado a seguir:

use config
db.settings.updateOne( { _id : "balancer" }, { $unset : { activeWindow : true } } )

Por padrão, o balanceador pode executar a qualquer momento e mover apenas os blocos conforme necessário. Para desabilitar o balanceador por um curto período de tempo e evitar toda a migração, use o seguinte procedimento:

  1. Conecte-se a qualquer mongos no cluster usando o shell mongosh .

  2. Comande a seguinte operação para desativar o balanceador:

    sh.stopBalancer()

    Se houver uma migração em andamento, o sistema concluirá a migração em andamento antes de encerrar.

    A partir do MongoDB 6.0.3, a divisão automática de chunks não é executada. Isso se deve às melhorias no balanceamento das políticas. Os comandos de divisão automática ainda existem, mas não executam uma operação.

    Nas versões do MongoDB anteriores à 6.0.3, sh.stopBalancer() também desativa a divisão automática do cluster fragmentado.

  3. Para verificar se o balancer não iniciará, execute o seguinte comando, que retornará false se o balancer estiver desabilitado:

    sh.getBalancerState()

    Opcionalmente, para verificar se nenhuma migração está em andamento após a desativação, execute a seguinte operação no shell mongosh :

    use config
    while( sh.isBalancerRunning() ) {
    print("waiting...");
    sleep(1000);
    }

Observação

Para desativar o balanceador a partir de um driver, use o comando balancerStop no banco de dados admin, como a seguir:

db.adminCommand( { balancerStop: 1 } )

Use este procedimento se você tiver desabilitado o balancer e estiver pronto para reativá-lo:

  1. Conecte-se a qualquer mongos no cluster usando o shell mongosh .

  2. Comande uma das seguintes operações para habilitar o balanceador:

    A partir do shell mongosh , emita:

    sh.startBalancer()

    Observação

    Para habilitar o balanceador a partir de um driver, use o comando BalancerStart no admin banco de dados , como mostrado a seguir:

    db.adminCommand( { balancerStart: 1 } )

    A partir do MongoDB 6.0.3, a divisão automática de chunks não é executada. Isso se deve às melhorias no balanceamento das políticas. Os comandos de divisão automática ainda existem, mas não executam uma operação.

    Nas versões MongoDB anteriores a 6.0.3, o sh.startBalancer() também habilita a divisão automática para o cluster fragmentado.

Observação

A desativação do balanceador só é necessária ao fazer backups manualmente , chamando mongodump ou agendando uma tarefa que chame mongodump em um horário específico.

Não é necessário desativar o balancer ao usar processos coordenados de backup e restauração:

Se o MongoDB migrar um bloco durante um backup, você poderá terminar com um instantâneo inconsistente do cluster fragmentado. Nunca execute um backup enquanto o balanceador estiver ativo. Para garantir que o balanceador esteja inativo durante a operação de backup:

Se você desligar o balanceador enquanto ele estiver no meio de uma rodada de balanceamento, o desligamento não será instantâneo. O balanceador completa o movimento do bloco em andamento e, em seguida, interrompe todas as rodadas de balanceamento adicionais.

Antes de iniciar uma operação de cópia de segurança, confirme se o balanceador não está ativo. Você pode usar o seguinte comando para determinar se o balanceador está ativo:

!sh.getBalancerState() && !sh.isBalancerRunning()

Quando o procedimento de backup estiver concluído, você poderá reativar o processo do balanceador.

Você pode desabilitar o balanceamento para uma collection específica com o método sh.disableBalancing(). Talvez você queira desabilitar o balancer para uma collection específica para permitir operações de manutenção ou volumes de trabalho atípicos, por exemplo, durante ingestões de dados ou exportações de dados.

Se você desabilitar o balanceamento em uma coleção, o MongoDB não interromperá as migrações em andamento.

Para desabilitar o balanceamento em uma coleção, conecte-se a um mongos com o shell mongosh e chame o método sh.disableBalancing() .

Por exemplo:

sh.disableBalancing("students.grades")

O método sh.disableBalancing() aceita como seu parâmetro o espaço de nomes completo da coleção.

Você pode habilitar o equilíbrio para uma coleção específica com o método sh.enableBalancing().

Quando você habilita o equilíbrio para uma coleção, o MongoDB não imediatamente começará a equilibrar dados. No entanto, se os dados em sua coleção fragmentada não estiverem balanceados, o MongoDB poderá começar a distribuir os dados de maneira mais uniforme.

Para ativar o balanceamento em uma coleção, conecte-se a um mongos com o shell mongosh e chame o método sh.enableBalancing() .

Por exemplo:

sh.enableBalancing("students.grades")

O método sh.enableBalancing() aceita como seu parâmetro o espaço de nomes completo da coleção.

Para confirmar se o balanceamento de uma coleção está ativado ou desativado, consulte a coleção collections no banco de dados config para obter o namespace da coleção e verifique o campo noBalance. Por exemplo:

db.getSiblingDB("config").collections.findOne({_id : "students.grades"}).noBalance;

Essa operação retornará um erro de valor null, true, false ou nenhuma saída:

  • Um erro de valor null indica que o namespace da collection está incorreto.

  • Se o resultado for true, o balanceamento será desativado.

  • Se o resultado for false, o equilíbrio está habilitado atualmente, mas foi desabilitado no passado para a coleção. O balanceamento dessa coleção começará na próxima vez que o balanceador for executado.

  • Se a operação não retornar saída, o balanceamento será habilitado atualmente e nunca foi desabilitado no passado para esta coleção. O balanceamento dessa coleção começará na próxima vez que o balanceador for executado.

Você também pode ver se o balanceador está ativado usando sh.status(). O campo currently-enabled indica se o balanceador está habilitado.

Durante a migração de bloco, o valor de _secondaryThrottle determina quando a migração prossegue com o próximo documento no bloco.

Na coleção config.settings:

  • Se a configuração _secondaryThrottle do balanceador for definida como write concern, cada documento movido durante a migração de chunk deverá receber a confirmação solicitada antes de prosseguir com o próximo documento.

  • Se a configuração _secondaryThrottle não for definida, o processo de migração não aguardará a replicação em um secundário e, em vez disso, continuará com o próximo documento.

    Este é o comportamento padrão para WiredTiger.

Para alterar a configuração do _secondaryThrottle , conecte a uma instância do mongos e atualize diretamente o valor do _secondaryThrottle na coleção settings do banco de dados de configuração. Por exemplo, a partir de um shell mongosh conectado a um mongos, execute o seguinte comando:

use config
db.settings.updateOne(
{ "_id" : "balancer" },
{ $set : { "_secondaryThrottle" : { "w": "majority" } } },
{ upsert : true }
)

Os efeitos de alterar a configuração do _secondaryThrottle podem não ser imediatos. Para garantir um efeito imediato, pare e reinicie o balanceador para habilitar o valor selecionado de _secondaryThrottle.

Para obter mais informações sobre o comportamento de replicação durante várias etapas da migração de bloco, consulte Intervalo de migração e replicação.

  • Utilize as opçõesmoveRangee secondaryThrottle do comando writeConcern para especificar o comportamento durante o comando.

  • Utilize as opçõesmoveChunke _secondaryThrottle do comando writeConcern para especificar o comportamento durante o comando.

Para detalhes, consulte moveRange e moveChunk.

A configuração _waitForDelete do balanceador e do comando moveChunk afetam a forma como o balanceador migra vários blocos de um fragmento. Da mesma forma, a configuração _waitForDelete do balanceador e o comando moveRange também afetam a forma como o balanceador migra vários blocos de um fragmento. Por padrão, o balanceador não espera que a fase de exclusão da migração em andamento seja concluída antes de iniciar a próxima migração de partes. Para que a fase de exclusão bloqueie o início da próxima migração de fragmento, você pode definir _waitForDelete como true.

Para obter detalhes sobre migração de chunk, consulte Migração de faixa. Para obter detalhes sobre o comportamento de enfileiramento da migração de chunk, consulte Limpeza de migração de faixa assíncrona.

O _waitForDelete geralmente é para fins de testes internos. Para alterar o valor _waitForDelete do balanceador:

  1. Conecte a uma instância do mongos.

  2. Atualize o valor do _waitForDelete na coleção settings do banco de dados de configuração. Por exemplo:

    use config
    db.settings.updateOne(
    { "_id" : "balancer" },
    { $set : { "_waitForDelete" : true } },
    { upsert : true }
    )

Após definir para true, reverta para o comportamento padrão:

  1. Conecte a uma instância do mongos.

  2. Atualize ou desmarque o campo _waitForDelete na coleção settings do banco de dados de configuração:

    use config
    db.settings.updateOne(
    { "_id" : "balancer", "_waitForDelete": true },
    { $unset : { "_waitForDelete" : "" } }
    )

Por padrão, o MongoDB não poderá mover uma faixa se o número de documentos dela for maior do que o dobro do resultado da divisão do tamanho da faixa configurado pelo tamanho médio do documento.

Ao especificar a configuração do balanceador attemptToBalanceJumboChunks como true, o balanceador pode migrar esses grandes intervalos, desde que não tenham sido rotulados como jumbo.

Para definir a configuração attemptToBalanceJumboChunks do balanceador, conecte-se a uma instância mongos e atualize diretamente a coleção config.settings . Por exemplo, em um shell mongosh conectado a uma instância mongos , execute o seguinte comando:

db.getSiblingDB("config").settings.updateOne(
{ _id: "balancer" },
{ $set: { attemptToBalanceJumboChunks : true } },
{ upsert: true }
)

Se a faixa que você deseja mover estiver rotulado como jumbo, você poderá limpar manualmente o sinalizador jumbo para que a balancer tente migrar a faixa.

Você também pode migrar manualmente os intervalos que excederem o limite de tamanho (com ou sem o rótulo jumbo) utilizando:

No entanto, quando você executa moveRange ou moveChunk com forceJumbo: true, as operações de gravação na coleção podem bloquear por um longo período de tempo durante a migração.

A alteração do tamanho máximo de armazenamento de um shard está obsoleta. A partir da versão 4,2, o MongoDB usa o WiredTiger Storage Engine para gerenciar como os dados são armazenados. O WiredTiger comprime dados para minimizar o uso do armazenamento. Para saber mais, consulte Compressão.

Para as versões 6.1 e anteriores do MongoDB, você ainda pode configurar um tamanho de armazenamento máximo para um determinado shard no cluster fragmentado utilizando o campo maxSize. Você pode encontrar dados de configuração relacionados a shards na collection config.shards .

Iniciando na versão 6.2, o MongoDB remove o campo maxSize do comando addShard. Como resultado:

  • Executar addShard com o campo maxSize retorna um erro InvalidOptions.

  • Novos documentos na collection shards não incluem mais o campo maxSize.

  • Quaisquer entradas de campo maxSize pré-existentes são ignoradas.

← Balanceador de cluster fragmentado