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 padrão do chunk
  • 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 3.4: O processo do balanceador passou das instâncias mongos para o membro primary do servidor de configuração do conjunto de réplicas.

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 Balanceador de Cluster.

sh.getBalancerState() verifica se o balanceador está habilitado (ou seja, se o balanceador tem permissão para ser executado). sh.getBalancerState() não verifica se o balancer está equilibrando ativamente os chunks.

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-se a qualquer mongos no cluster usando o shell mongo .

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

    sh.isBalancerRunning()

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

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.

Para configurar o tamanho padrão do chunk, consulte Modificar o tamanho do chunk 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 4.2, 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-se a qualquer mongos no cluster usando o shell mongo .

  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 4.2, sh.stopBalancer() também desabilita a divisão automática para o 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 desativação, emita a seguinte operação no shell mongo :

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

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

    A partir do shell mongo , 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 4.2, 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 mongo 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 mongo 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.

_secondaryThrottle mongos Para alterar a _secondaryThrottle configuração do , conecte a uma instância do e atualize diretamente o valor do na coleção do settings banco de dados de configuração . Por exemplo, a partir de um shell mongo conectado a um mongos, emita 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 da replicação durante várias etapas da migração de chunk, consulte Migração e replicação de chunk.

Para o comando moveChunk , você pode utilizar as opções _secondaryThrottle e writeConcern do comando para especificar o comportamento durante o comando. Para obter detalhes, consulte o comando moveChunk .

A configuração _waitForDelete do balanceador e do comando moveChunk 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 chunk. Para obter detalhes sobre o comportamento de enfileiramento da migração de chunk, consulte Limpeza assíncrona de migração de chunk.

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 um chunk se o número de documentos no chunk for maior que 1.3 vezes o resultado da divisão do tamanho do chunk 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, a partir de um shell mongo conectado a uma instância do mongos , emita o seguinte comando:

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

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

Como alternativa, você pode usar o comando moveChunk com forceJumbo: true para migrar manualmente os blocos que excedem o limite de tamanho (com ou sem o rótulo jumbo ). No entanto, quando você executa 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 mongo 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