O balanceador MongoDB é um processo de plano de fundo que monitora o número de blocos em cada fragmento. Quando o número de blocos em um determinado fragmento atinge limites de migração específicos, o balanceador tenta migrar automaticamente os blocos entre fragmentos e alcançar um número igual de blocos por fragmento.
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 os chunks de uma collection fragmentada uniformemente entre os shards 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.
Migrações de chunks podem ter impacto no espaço em disco, pois o fragmento de origem arquiva automaticamente os documentos migrados por padrão. Para obter detalhes, consulte o diretóriomoveChunk .
As migrações de chunks carregam algumas despesas indiretas em termos 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 um fragmento a no máximo uma migração por vez; ou seja, um fragmento não pode participar de várias migrações de chunks ao mesmo tempo. Para migrar vários blocos de um fragmento, o balanceador migra os blocos um de cada vez.
Alterado na versão 3.4: A partir do MongoDB 3.4, O MongoDB pode executar migrações de chunks 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 chunks.
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 desabilitar o balanceador temporariamente para manutenção, mas deixar o balanceador desabilitado por longos períodos de tempo pode degradar o desempenho do cluster. Para mais informações, consulte Desabilitar o Balancer.
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.
| [1] | A operação de collection de fragmentos pode executar uma criação e distribuição inicial de chunks para collections vazias ou inexistentes se as zonas e as zona de zonas tiverem sido definidas para a collection. A criação e distribuição inicial de chunks agiliza a configuração da fragmentação por zonas. Após a distribuição inicial, o balanceador gerenciará normalmente a distribuição de chunks daqui para a frente. O MongoDB oferece suporte a collections de fragmentação em índices com hash compostos. Ao fragmentar uma collection vazia ou inexistente usando uma chave de fragmento com hash composto, aplicam-se requisitos adicionais para que o MongoDB execute a criação e a distribuição inicial do chunk.Consulte Predefinir zonas e faixas de 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 partes. 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 um fragmento de um cluster cria um desequilíbrio semelhante, pois os blocos que residem nesse fragmento devem ser redistribuídos por todo o cluster. Enquanto o MongoDB começa a drenar um fragmento removido imediatamente, pode levar algum tempo até que o cluster equilibre. Não desligue os servidores associados 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 Remove Shards from an Existing Sharded Cluster (Remover fragmentos de um cluster fragmentado existente) para obter instruções sobre como remover com segurança um fragmento de um cluster.
Procedimento de Migração de Bloco
Todas as migrações de chunk 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 o chunk são roteadas para o shard de origem. O fragmento de origem é responsável pelas operações de escrita recebidas para o chunk.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 no chunk, o shard de destino inicia um processo de sincronização para garantir que ele faça as alterações nos documentos migrados que ocorreram durante a migração.
Quando totalmente sincronizado, o shard de origem se conecta ao 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 como não houver cursores abertos no bloco, o fragmento de origem exclui sua cópia dos documentos.
Observação
Se o balanceador precisar executar migrações de chunk adicionais do fragmento de origem, balanceador 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.
O processo de migração garante consistência e maximiza a disponibilidade de chunks durante o balanceamento.
Aviso
Leituras secundárias em um cluster fragmentado com migrações podem perder documentos
As leituras secundárias de longa duração em um cluster fragmentado podem perder documentos se estiverem ocorrendo migrações.
Antes de excluir um fragmento durante a migração do fragmento, o MongoDB espera que orphanCleanupDelaySecs ou que as queries em andamento envolvendo o fragmento sejam concluídas no fragmento primário, o que for mais longo. As queries que foram executadas inicialmente em um nó primário, mas continuam após o nó passar para um secundário, serão tratadas como se tivessem sido executadas inicialmente em um secundário. Ou seja, o servidor só espera por orphanDelayCleanupSecs se não houver queries direcionadas à parte do primário atual.
As queries que têm como alvo a parte e são executadas em réplicas secundárias podem perder documentos se levarem mais de orphanCleanupDelaySecs.
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 coleção fragmentada atinge o limite de migração que torna o cluster desequilibrado. Quando o número de blocos no fragmento mais carregado excede o número ideal de blocos por fragmento em mais de 1 blocos, a coleção é desequilibrada e o balanceador inicia migrações de blocos. O número ideal de chunks por shard é o número total de chunks em uma collection fragmentada 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 chunks com base em cada zona.
Por exemplo, se um usuário adicionar um novo shard a uma collection de 10 shards com 20 chunks cada, o balancer não migrará nenhum dado. O número ideal de chunks 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 chunk para o novo shard.
Limpeza da Migração de Bloco Assíncrona
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 chunk para saber o processo de migração de chunk e a fase de exclusão.
Esse comportamento de enfileiramento permite que os fragmentos descarreguem chunks 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 chunks foram aprimoradas para serem mais resilientes no evento de um failover durante a fase de exclusão. Os documentos órfãos 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 chunk. O _waitForDelete geralmente é para fins de testes internos. Para mais informações, consulte Aguardar exclusão.
Observação
A exclusão de intervalo é uma operação de uso intensivo de recursos que pode resultar em estresse significativo de cache e E/S à medida que o cluster exclui os documentos.
Nos casos em que você planeja mover uma grande quantidade de dados, como ao adicionar fragmentos a um cluster ou durante a distribuição inicial de uma coleção fragmentada em vários fragmentos, considere refragmentar a coleção. As operações de refragmentação não exigem limpeza de intervalo, o que as torna muito menos estresse no cluster.
Para mais informações, consulte Refragmentar uma collection.
Migração e replicação de chunks
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
_secondaryThrottlepara o balanceador estiver definida como uma preocupação de gravação, 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 chunks têm a seguinte política de replicação:
O MongoDB pausa brevemente todas as leituras e gravações do aplicação na coleção que está sendo migrada, no fragmento de origem, antes de atualizar os servidores de configuração com o novo local para o chunk e retoma as leituras e gravações do aplicação após a atualização. A movimentação de chunks 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 chunks nos servidores de configuração.
Quando uma migração de chunk de saída é concluída e ocorre a limpeza, todas as gravações devem ser replicadas para a maioria dos servidores antes que a limpeza adicional (de outras migrações 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 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. db.collection.stats() inclui o campo avgObjSize , que representa o tamanho médio do documento na coleção.
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 os blocos grandes demais para serem movidos, desde que os blocos não sejam rotulados como jumbo. Consulte Balancear Blocos que Excedem o Limite de Tamanho para obter detalhes.O comando
moveChunkpode especificar uma nova opção forceJumbo para permitir a migração de partes que são muito grandes para serem movidas. As partes podem ser rotuladas de jumbo ou não.
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.