Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Balanceador de cluster fragmentado
O balanceador MongoDB é um processo de plano de fundo que monitora o número de blocos em cada fragmento. Quando o número de chunks em um determinado shard atinge limites de migração específicos, o balancer tenta migrar automaticamente chunks entre shards e alcançar um número igual de chunks por shard.
O procedimento de balanceamento para clusters fragmentados é totalmente transparente para o usuário e a camada do aplicativo, embora possa haver algum impacto no desempenho durante a execução do procedimento.
O balanceador executa na primária do conjunto de réplicas do servidor de configuração (CSRS).
balancer de cluster
O processo do balanceador é responsável por redistribuir as partes de uma collection fragmentada uniformemente entre os fragmentos para cada collection fragmentada. Por padrão, o processo de balanceador está sempre ativado.
Para resolver a distribuição desigual de chunks em uma collection fragmentada, o balanceador migra chunks de shards com mais chunks para shards com um número menor de chunks. O balanceador migra os blocos até que haja uma distribuição uniforme de blocos para a coleção entre os fragmentos. Para obter detalhes sobre migração de chunk, consulte Procedimento de migração de chunk.
As migrações de parte podem ter um impacto no espaço em disco, pois o shard de origem arquiva automaticamente os documento migrados por padrão. Para detalhes, consulte moveChunk diretório.
As migrações de parte carregam algumas despesas indiretas em termo de largura de banda e carga de trabalho, ambas podendo afetar o desempenho do banco de dados. [1] O balanceador tenta minimizar o impacto por:
Restringir uma parte a no máximo uma migração por vez; ou seja, uma parte não pode participar de várias migrações de parte ao mesmo tempo. Para migrar várias partes de uma parte, o balanceador migra as partes uma de cada vez.
Alterado na versão 3.4: Começando no MongoDB 3.4, o MongoDB pode executar migrações de partes paralelas. Observando a restrição de que um fragmento pode participar de, no máximo, uma migração por vez, para um cluster fragmentado com n fragmentos, o MongoDB pode executar no máximo n/2 (arredondado para baixo) migrações simultâneas de partes.
Consulte também Limpeza de migração de bloco assíncrona.
Iniciar uma rodada de balanceamento somente quando a diferença no número de blocos entre o fragmento com o maior número de blocos para uma coleção fragmentada e o fragmento com o menor número de blocos para essa coleção atingir o limite de migração.
Você pode desativar o balanceador temporariamente para manutenção. Consulte Desabilitar o Balanceador para detalhes.
Você também pode limitar a janela durante a qual o balanceador é executado para evitar que ele afete o tráfego de produção. Consulte Agendar a janela de balanceamento para obter detalhes.
Observação
A especificação da janela de balanceamento é relativa ao fuso horário local da primária do conjunto de réplicas do servidor de configuração.
Dica
Veja também:
| [1] | A partir do MongoDB 4.0.3, a operação de collection pode executar uma criação e distribuição inicial de parte para collection vazias ou inexistentes se as zona e as zona tiverem sido definidas para a collection. A criação e distribuição inicial de parte agiliza a configuração da zona. Após a distribuição inicial, o balanceador managed a distribuição de parte daqui para frente, como de costume.O MongoDB oferece suporte a collection em chave de fragmento com hash. Ao fragmentar uma collection vazia ou inexistente usando uma chave de fragmento com hash, aplicam-se requisitos adicionais para que o MongoDB execute a criação e a distribuição inicial do parte.Consulte Predefinir zona e zona para uma collection vazia ou não existente para obter um exemplo . |
Adicionar e remover fragmentos do cluster
Adicionar um fragmento a um cluster cria um desequilíbrio, pois o novo fragmento não tem parte. Enquanto o MongoDB começa a migrar dados para o novo fragmento imediatamente, pode levar algum tempo até que o cluster equilibre. Consulte o tutorial Adicionar fragmentos a um cluster para obter instruções sobre como adicionar um fragmento a um cluster.
A remoção de uma parte de um cluster cria um desequilíbrio semelhante, pois as partes que residem nesse fragmento devem ser redistribuídas por todo o cluster. Enquanto o MongoDB começa a drenagem de um fragmento removido imediatamente, pode levar algum tempo até que o cluster equilibre. Não desligue o servidor associado ao fragmento removido durante esse processo.
Quando você remove um fragmento em um cluster com uma distribuição desigual de fragmentos, o balanceador primeiro remove os fragmentos do fragmento de drenagem e, em seguida, equilibra a distribuição desigual de fragmentos restante.
Consulte o tutorial Remover fragmentos de um cluster fragmentado existente para obter instruções sobre como remover com segurança um fragmento de um cluster.
Dica
Veja também:
Procedimento de migração de parte
Todas as migrações de parte usam o seguinte procedimento:
O processo do balanceador envia o comando
moveChunkpara o fragmento de origem.A origem inicia a transferência com um comando
moveChunkinterno. Durante o processo de migração, as operações para a parte são roteadas para o shard de origem. O fragmento de origem é responsável pelas operações de escrita recebidas para a parte.O fragmento de destino cria todos os índices exigidos pela origem que não existem no destino.
O fragmento de destino começa a solicitar documentos no bloco e começa a receber cópias dos dados. Consulte também Migração e replicação de chunks.
Depois de receber o documento final na parte, o fragmento de destino inicia um processo de sincronização para garantir que tenha as alterações no documento migrado que ocorreram durante a migração.
Quando totalmente sincronizado, o fragmento de origem se conecta ao reconhecimento de data center banco de dados de configuração e atualiza os metadados do cluster com o novo local do chunk.
Depois que o fragmento de origem concluir a atualização dos metadados e quando não houver cursor abertos na parte, o fragmento de origem exclui sua cópia do documento.
Observação
Se o balanceador precisar executar migrações de chunk adicionais do fragmento de origem, ele poderá iniciar a próxima migração de chunk sem esperar que o processo de migração atual termine essa etapa de exclusão. Consulte Limpeza de migração de chunk assíncrona.
Dica
Veja também:
O processo de migração garante consistência e maximiza a disponibilidade de parte durante o balanceamento.
Dica
Veja também:
Limites de migração
Para minimizar o impacto do balanceamento no cluster, o balanceador começa a fazer o balanceamento somente depois que a distribuição de dados de uma collection atinge o limite de migração que torna o cluster desequilibrado. Quando o número de partes no fragmento mais carregado excede o número ideal de partes por fragmento em mais de 1 partes, a collection é desequilibrada e o balanceador inicia migrações de partes. O número ideal de partes por shard é o número total de partes em uma collection dividido pelo número de shards, arredondado para o número inteiro mais próximo. Se existirem zonas, o MongoDB calcula o número ideal de partes com base em cada zona.
Por exemplo, se um usuário adicionar um novo shard a uma collection de 10 shards com 20 parte cada, o balanceador não migrará nenhum dado. O número ideal de parte em cada shard é 200 dividido por 11 ou 18.18, que o MongoDB arredonda para 19. Como a diferença entre 19 e 20 é 1, o cluster é balanceado e o balanceador não migra nenhum parte para o novo shard.
Dica
Veja também:
Limpeza de Migração de parte Assíncrono
Para migrar vários blocos de um fragmento, o balanceador migra os blocos um de cada vez. No entanto, o balanceador não aguarda a conclusão da fase de exclusão da migração atual antes de iniciar a próxima migração de partes. Consulte Migração de chunks para saber o processo de migração de chunks e a fase de exclusão.
Esse comportamento de enfileiramento permite que os fragmentos baixem as partes mais rapidamente em casos de cluster altamente desequilibrado, como ao realizar carregamentos iniciais de dados sem pré-divisão e ao adicionar novos fragmentos.
Este comportamento também afeta o comando moveChunk e scripts de migração que utilizam o comando moveChunk podem prosseguir mais rapidamente.
Em alguns casos, as fases de exclusão podem persistir por mais tempo. A partir do MongoDB 4.4, as migrações de parte são aprimoradas para serem mais resilientes no caso de um evento durante a fase de exclusão. Os documento órfão são limpos mesmo se o conjunto de réplicas principal falhar ou recomeçar durante essa fase.
O _waitForDelete, disponível como uma configuração para o balanceador, bem como o comando moveChunk , pode alterar o comportamento de forma que a fase de exclusão da migração atual bloqueie o início da próxima migração de parte. O _waitForDelete geralmente é para fins de testes internos. Para obter mais informações, consulte Aguardar exclusão.
Migração e replicação de partes
Alterado na versão 3.4.
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
_secondaryThrottledo balanceador for definida como um write concern, cada documento movido durante a migração de intervalo deverá receber a confirmação solicitada antes de prosseguir com o próximo documento.Se a configuração
_secondaryThrottlenã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.
Para atualizar o parâmetro _secondaryThrottle para o balanceador, consulte Acelerador secundário para obter um exemplo.
Independentemente de qualquer configuração de _secondaryThrottle, determinadas fases da migração de parte têm a seguinte política de replicação:
O MongoDB pausa brevemente todas as leituras e gravações da aplicação na collection que está sendo migrada, no fragmento de origem, antes de atualizar o servidor de configuração com o novo local da parte e retoma as leituras e gravações da aplicação após a atualização. A movimentação de partes exige que todas as gravações sejam reconhecidas pela maioria dos membros do conjunto de réplicas antes e depois de confirmar a movimentação de partes no servidor de configuração.
Quando uma migração de parte de saída é concluída e ocorre a limpeza, todas as gravações devem ser replicadas para a maioria dos servidor antes que uma limpeza adicional (de outras migrações de parte de saída) ou novas migrações de entrada possam prosseguir.
Para atualizar a configuração do _secondaryThrottle na coleção config.settings, consulte Aceleramento secundário para um exemplo.
Número máximo de documento por parte para migração
Por padrão, o MongoDB não poderá mover uma parte se o número de documento na parte for maior que 1.3 vezes o resultado da divisão do tamanho da parte configurada pelo tamanho médio do documento. db.collection.stats() inclui o campo avgObjSize , que representa o tamanho médio do documento na collection.
Para chunks que são muito grandes para serem migrados, começando no MongoDB 4.4:
Uma nova configuração de balanceador
attemptToBalanceJumboChunkspermite que o balanceador migre as partes grandes demais para serem movidas, desde que as partes não sejam rotuladas como jumbo. Consulte Balancear partes que excedem o limite de tamanho para detalhes.O comando
moveChunkpode especificar uma nova opção forceJumbo para permitir a migração de chunks que são muito grandes para serem movidos. Os pedaços podem ou não ser rotulados como jumbo.
Ajuste de desempenho de exclusão de intervalo
Você pode ajustar o impacto no desempenho das exclusões de intervalo com rangeDeleterBatchSize e rangeDeleterBatchDelayMS parâmetros. Por exemplo:
Para limitar o número de documentos excluídos por lote, você pode definir
rangeDeleterBatchSizepara um valor pequeno, como32.Para adicionar um atraso adicional entre as exclusões em lote, você pode definir
rangeDeleterBatchDelayMSacima do padrão atual de20milissegundos.
Observação
Se houver operações de leitura em andamento ou cursores abertos na coleção destinada a exclusões, os processos de exclusão de intervalo podem não continuar.
Tamanho do fragmento
Por padrão, o MongoDB tenta preencher todo o espaço em disco disponível com dados em cada fragmento à medida que o conjunto de dados cresce. Para garantir que o cluster sempre tenha a capacidade de lidar com o crescimento dos dados, monitore o uso do disco, bem como outras métricas de desempenho.
Consulte o tutorial Alterar o tamanho máximo de armazenamento para um determinado fragmento para obter instruções sobre como configurar o tamanho máximo para um fragmento.