Balanceador de cluster fragmentado
Nesta página
O balanceador MongoDB é um processo de plano de fundo que monitora a quantidade de dados em cada fragmento para cada coleção fragmentada. Quando a quantidade de dados de uma coleção fragmentada em um determinado fragmento atinge limites de migração específicos, o balanceador tenta migrar automaticamente os dados entre fragmentos e atingir uma quantidade uniforme de dados por fragmento, respeitando as zonas. Por padrão, o processo de balanceador está sempre ativado.
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).
Para configurar o balanceamento de coleção para uma única coleção, consulte configureCollectionBalancing.
Para gerenciar o balanceador de cluster fragmentado, consulte Gerenciar balanceador de cluster fragmentado.
Internos do balanceador
As migrações de faixa carregam algumas despesas indiretas em termos de largura de banda e carga de trabalho, ambas podendo afetar o desempenho do banco de dados. O balanceador tenta minimizar o impacto por:
Restringir um fragmento a no máximo uma migração por vez. Especificamente, um fragmento não pode participar de várias migrações de dados ao mesmo tempo. O balanceador migra os intervalos um de cada vez.
O MongoDB pode executar migrações de dados paralelas, mas 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.
Consulte também Limpeza de migração de faixa assíncrona.
Iniciar uma rodada de balanceamento somente quando a diferença na quantidade de dados entre o fragmento com mais dados para uma coleção fragmentada e o fragmento com menos dados 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.
Adicionar e remover fragmentos do cluster
Adicionar um fragmento a um cluster cria um desequilíbrio, pois o novo fragmento não tem dados. 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.
Dica
Se seu aplicação atender ao Antes de começar, você poderá usar o comando reshardCollection para redistribuir dados pelo cluster e incluir os novos fragmentos. Esse processo é muito mais rápido do que o procedimento alternativo de migração de intervalo.
Para obter um exemplo, consulte Redistribuir dados para novos shards.
A remoção de um fragmento de um cluster cria um desequilíbrio semelhante, pois os dados 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 a Cluster (Remover fragmentos de um cluster) para obter instruções sobre como remover com segurança um fragmento de um cluster.
Procedimento de migração de faixa
Todas as migrações de faixa usam o seguinte procedimento:
O processo do balanceador envia o comando
moveRangepara o fragmento de origem.A origem inicia a transferência quando recebe um comando
moveRangeinterno. Durante o processo de migração, as operações para a faixa são enviadas para o fragmento de origem. O fragmento de origem é responsável pelas operações de escrita recebidas para a faixa.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 intervalo e começa a receber cópias dos dados. Consulte também Migração e replicação de faixa.
Depois de receber o documento final no intervalo, o fragmento de destino inicia um processo de sincronização para garantir que ele tenha as alterações nos documentos migrados que ocorreram durante a migração.
Quando totalmente sincronizado, o fragmento de origem se conecta ao banco de dados de configuração e atualiza os metadados do cluster com o novo local do intervalo.
Depois que o fragmento de origem concluir a atualização dos metadados e quando não houver cursores abertos no intervalo, o fragmento de origem excluirá sua cópia dos documentos.
Observação
Se o balanceador precisar executar migrações de parte adicionais do fragmento de origem, ele poderá iniciar a próxima migração de parte sem esperar que o processo de migração atual termine essa etapa de exclusão.Consulte Limpeza da migração de faixa assíncrona.
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 só começa a fazer o balanceamento depois que a distribuição de dados de uma coleção fragmentada atinge determinados limites.
Uma coleção é considerada balanceada se a diferença de dados entre fragmentos (para aquela coleção) for menor que três vezes o tamanho do intervalo configurado para a coleção. Para o tamanho de intervalo padrão de 128MB, dois fragmentos devem ter uma diferença de tamanho de dados para uma determinada coleção de pelo menos 384MB para que uma migração ocorra.
Limpeza da Migração de Intervalo Assíncrona
Para migrar dados de um fragmento, o balanceador migra os dados um intervalo 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 intervalo. Consulte Migração de intervalo para obter informações sobre o processo de migração de intervalo e a fase de exclusão.
Esse comportamento de enfileiramento permite que os fragmentos descarreguem dados 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 moveRange e scripts de migração que utilizam o comando moveRange podem prosseguir mais rapidamente.
Em alguns casos, as fases de exclusão podem persistir por mais tempo. As migrações de intervalo são aprimoradas para serem mais resilientes no caso 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.
A configuração do balanceador do _waitForDelete 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 intervalo
Durante a migração de intervalo, o valor _secondaryThrottle determina quando a migração prossegue com o próximo documento no intervalo.
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 intervalo têm a seguinte política de replicação:
O MongoDB pausa brevemente todas as leituras e gravações do aplicativo na coleção que está sendo migrada para o fragmento de origem antes de atualizar os servidores de configuração com o local do intervalo. O MongoDB retoma as leituras e gravações do aplicativo após a atualização. A movimentação de intervalo 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 intervalo nos servidores de configuração.
Quando uma migração de saída é concluída e a limpeza ocorre, todas as gravações devem ser replicadas para a maioria dos servidores antes que outras limpezas (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 documentos por intervalo para migração
Por padrão, o MongoDB não poderá mover um intervalo se o número de documentos do intervalo for maior do que o dobro do resultado da divisão do tamanho do intervalo configurado pelo tamanho médio do documento. Se o MongoDB puder mover um subintervalo de um bloco e reduzir o tamanho para menos do que isso, o balanceador o fará migrando um intervalo. db.collection.stats() inclui o campo avgObjSize, que representa o tamanho médio do documento na coleção.
Para partes que são muito grandes para serem migradas:
A configuração do balanceador
attemptToBalanceJumboChunkspermite que o balanceador migre os blocos grandes demais para serem movidos, desde que os blocos não sejam rotulados como jumbo. Consulte Intervalos de equilíbrio que excedem o limite de tamanho para detalhes.Ao emitir comandos do
moveRangeemoveChunk, é possível especificar a opção forceJumbo para permitir a migração de intervalos que são muito grandes para mover. Os intervalos 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 rangeDeleterBatchSizeparâmetros , rangeDeleterBatchDelayMSe rangeDeleterHighPriority. 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.Para priorizar exclusões de intervalo, você pode configurar
rangeDeleterHighPriorityparatrue. As exclusões de intervalo são tarefas em segundo plano potencialmente de longa execução que podem afetar negativamente a taxa de transferência das operações do usuário quando o sistema está sob carga pesada.
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.
Alterar fluxos e documentos órfãos
A partir do MongoDB 5.3, durante a migração de faixa, os eventos de change stream não são gerados para atualizações de documentos órfãos.
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.
Tamanho e balanceamento do pedaço
Para uma introdução ao chunkSize, consulte Modificar o Tamanho do Intervalo em um Cluster fragmentado.
A tabela a seguir descreve como o chunkSize afeta a desfragmentação e as operações do balanceador em diferentes versões MongoDB.
Versão do MongoDB | Descrição |
|---|---|
MongoDB 6.0 e posterior | Quando os dados de coleta compartilhados entre dois estilhaços diferem em três ou mais vezes a configuração de Por exemplo, se |
Mais cedo do que MongoDB 6.0 | Quando um pedaço fica maior que chunkSize, o pedaço é dividido. |
Quando blocos são movidos, divididos ou mesclados, os metadados do fragmento são atualizados após a operação do bloco ser cometida por um servidor de configuração. Os fragmentos não envolvidos na operação de bloco também são atualizados com novos metadados.
O tempo para a atualização de metadados do fragmento é proporcional ao tamanho da tabela de roteamento. As operações CRUD na coleção são temporariamente bloqueadas enquanto os metadados de fragmento são atualizados, e uma tabela de roteamento menor significa atrasos de operação CRUD mais curtos.
Desfragmentar uma coleção reduz o número de blocos e o tempo para atualizar os metadados de bloco.
Para reduzir a carga de trabalho do sistema, configure o balanceador para ser executado somente em um horário específico usando uma janela de balanceamento de fragmentos. A desfragmentação é executada durante o período da janela de equilíbrio.
Você pode utilizar o parâmetro chunkDefragmentationThrottlingMS para limitar a taxa de comandos de divisão e mesclagem executados pelo balanceador.
Você pode iniciar e parar a desfragmentação a qualquer momento.
Você também pode definir uma zona de fragmento. Uma zona de fragmento é baseada na chave de fragmento e você pode associar cada zona a um ou mais fragmentos em um cluster.
A partir do MongoDB 6.0, um cluster fragmentado divide apenas as partes quando as partes devem ser migradas. Isso significa que o tamanho da parte pode exceder chunkSize. Blocos maiores reduzem o número de blocos em um fragmento e melhoram o desempenho porque o tempo para atualizar os metadados do fragmento é reduzido. Por exemplo, você pode ver um bloco de 1 TB em um fragmento, mesmo que tenha configurado chunkSize para 256 MB.
chunkSize afeta o seguinte:
Quantidade máxima de dados que o balanceador tenta migrar entre dois fragmentos em uma única operação de migração de bloco.
Quantidade de dados migrados durante a desfragmentação.
Para obter detalhes sobre como desfragmentar coleções fragmentadas, consulte Desfragmentar coleções fragmentadas.