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.
Verifique o estado do balancer
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.
Verifique se o balanceador está em execução
Para ver se o processo do balanceador está ativo em seu agrupamento:
Configurar tamanho do intervalo padrão
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.
Agendamento da janela de balanceamento
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:
Mudar para o banco de dados de configuração.
Dê o seguinte comando para passar para o banco de dados de configuração.
use config
Verifique se o balanceador não é stopped
.
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.
Modifique a janela do balanceador.
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 de00
a23
.Para o valor
MM
, use valores de minuto que variam de00
a59
.
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.
Remoção de um agendamento de janela de balanceamento
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 } } )
Desabilitar o balancer
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:
Conecte a qualquer
mongos
no cluster utilizando o shellmongosh
.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.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 } )
Habilite o balanceador
Use este procedimento se você tiver desabilitado o balancer e estiver pronto para reativá-lo:
Conecte a qualquer
mongos
no cluster utilizando o shellmongosh
.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.
Desativação do balanceamento durante backups
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:
Defina a janela de balanceamento para que o balanceador fique inativo durante o backup. Certifique-se de que o backup possa ser concluído enquanto você desativa o balanceador.
Desative manualmente o balanceador durante o procedimento 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.
Desativação do balanceamento em uma collection
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.
Como habilitar o balanceamento em uma 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.
Verifique se o equilíbrio está ativado ou desativado
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.
Alteração do comportamento de replicação para migração de partes
Acelerador secundário
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ções
moveRange
esecondaryThrottle
do comandowriteConcern
para especificar o comportamento durante o comando.Utilize as opções
moveChunk
e_secondaryThrottle
do comandowriteConcern
para especificar o comportamento durante o comando.
Para detalhes, consulte moveRange
e moveChunk
.
Aguarde a exclusão
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:
Conecte a uma instância do
mongos
.Atualize o valor do
_waitForDelete
na coleçãosettings
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:
Conecte a uma instância do
mongos
.Atualize ou desmarque o campo
_waitForDelete
na coleçãosettings
do banco de dados de configuração:use config db.settings.updateOne( { "_id" : "balancer", "_waitForDelete": true }, { $unset : { "_waitForDelete" : "" } } )
Intervalos de balanceamento que excedem o limite do tamanho
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:
o comando
moveRange
com a opção forceJumbo: trueo comando
moveChunk
com a opção forceJumbo: true
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.
Altere o tamanho máximo do armazenamento der um determinado shard
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 } )