Menu Docs
Página inicial do Docs
/
Manual 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.0.

Esta página descreve os procedimentos administrativos comuns relacionados ao balanceamento. Para uma introdução ao balanceamento, consulte Balanceador de cluster fragmentado. Para informações de nível inferior sobre balanceamento, consulte Internos do balanceador.

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á habilitado no seu cluster fragmentado, execute o seguinte comando, que retorna um booleano:

sh.getBalancerState()

Você também pode ver se o balanceador está habilitado 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 a qualquer mongos no cluster utilizando o shell do 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 alteração do tamanho padrão da parte afeta as partes que são processos durante as migrações e a divisão automática, mas não afeta todas as partes de forma retroativa.

A partir do MongoDB 6.0.3, a divisão automática de partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Para obter detalhes, consulte Alterações na política de balanceamento.

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 partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Para obter detalhes, consulte Alterações na política de balanceamento.

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ê tiver definido a janela de balanceamento e quiser remover a programação para que o balanceador esteja sempre em execução, use $unset para limpar o activeWindow, como no exemplo a seguir:

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

Importante

Deixar o balanceador desativado por longos períodos de tempo pode levar a shards desequilibrados, que degradam o desempenho do cluster. Desative o balanceador apenas se necessário e certifique-se de reativar o balanceador quando a manutenção for concluída.

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 a qualquer mongos no cluster utilizando 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 partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Para obter detalhes, consulte Alterações na política de balanceamento.

    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 balanceador não iniciará, execute o seguinte comando, que retornará false se o balanceador estiver desabilitado:

    sh.getBalancerState()

    Opcionalmente, para verificar se nenhuma migração está em andamento após a desabilitaçã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 a qualquer mongos no cluster utilizando o shell mongosh.

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

    A partir da shell mongosh, execute:

    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 partes não é executada. Isso se deve a melhorias na política de balanceamento. Os comandos de divisão automática ainda existem, mas não executam uma operação. Para obter detalhes, consulte Alterações na política de balanceamento.

    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 para o balanceador estiver definida como uma preocupação de gravação, cada documento movido durante a migração de parte 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, em 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, ele 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.

Por padrão, os shards não têm restrições de tamanho de armazenamento. No entanto, você pode definir um tamanho máximo de armazenamento para um determinado fragmento no cluster fragmentado. Ao selecionar possíveis shards de destino, o balancer ignora os shards em que uma migração excederia o tamanho máximo de armazenamento configurado.

A coleção shards no banco de dados de configuração armazena dados de configuração relacionados a shards.

{ "_id" : "shard0000", "host" : "shard1.example.com:27100" }
{ "_id" : "shard0001", "host" : "shard2.example.com:27200" }

Para limitar o tamanho do armazenamento de um determinado shard, utilize o método db.collection.updateOne() com o operador $set para criar o campo maxSize e atribuir a ele um valor integer . O campo maxSize representa o tamanho máximo do armazenamento para o shard no megabytes.

A seguinte operação define um tamanho máximo em um shard de 1024 megabytes:

config = db.getSiblingDB("config")
config.shards.updateOne( { "_id" : "<shard>"}, { $set : { "maxSize" : 1024 } } )

Esse valor inclui o tamanho mapeado de todos os Data Federation no shard, incluindo os reconhecimento de data center local e admin .

Por padrão, o maxSize não é especificado, permitindo que os fragmentos consumam a quantidade total de espaço disponível em suas máquinas, se necessário.

Você também pode configurar o maxSize ao adicionar um fragmento.

Para definir maxSize ao adicionar um fragmento, defina o parâmetro maxSize addShard comando para o tamanho máximo em megabytes. O seguinte comando executado na shell mongosh adiciona um shard com um tamanho máximo de 125 megabytes:

config = db.getSiblingDB("config")
config.runCommand( { addshard : "example.net:34008", maxSize : 125 } )

Voltar

Balancer