Home Arrow Icon Knowledge base Arrow Icon Global Arrow Icon Como o MongoDB lida com a migração de dados entre fragmentos


Como o MongoDB lida com a migração de dados entre fragmentos


O MongoDB lida com a migração de dados entre fragmentos principalmente por meio de um processo chamado Migração de Chunk, que é parte integrante da arquitetura de sharding projetada para distribuir dados uniformemente em vários fragmentos em um cluster. O sharding em MongoDB é o método usado para escalar horizontalmente o banco de dados, particionando dados em vários servidores ou fragmentos. Este sistema utiliza uma chave de shard, que é um campo ou conjunto de campos em um documento que determina a distribuição de dados. Para gerenciar a migração de dados entre os shards, o MongoDB usa um processo de fundo chamado Balancer, que otimiza a distribuição de dados por migrando intervalos de dados (ou pedaços) conforme necessário.

Visão geral da migração de cluster e pedaços de cluster e pedaços

O MongoDB divide as coleções Sharded em pedaços, que são faixas contíguas de valores -chave do Shard. Cada pedaço pertence a um fragmento específico, e esses pedaços mantêm coletivamente todo o conjunto de dados. O balanceador monitora a distribuição de pedaços em fragmentos e migra pedaços entre fragmentos para manter o equilíbrio. Esse mecanismo de migração ajuda a evitar pontos de acesso, melhorar o desempenho da consulta e otimizar a utilização de recursos.

A migração de chunk é benéfica em cenários como quando novos fragmentos são adicionados a um cluster, quando os dados crescem desigualmente causando desequilíbrio ou quando as zonas precisam ser redefinidas para localidade de dados ou requisitos regulatórios. A migração opera no nível do pedaço, movendo uma gama inteira de valores de chave do Shard de um Shard para outro.

Detalhes do processo de migração

A migração de pedaços de MongoDB funciona em várias fases:

1. Seleção de pedaços para mover: o balanceador ou um administrador seleciona um pedaço que precisa de reatribuição a outro Shard para equilibrar o cluster.

2. Fase do clone: ​​o Shard doador (aquele que atualmente segura o pedaço) copia todos os documentos no pedaço do fragmento de destinatário. Durante esse período, novas gravações para o pedaço no Shard doador também são rastreadas.

3. Fase de recuperação: o Shard destinatário aplica quaisquer gravações que ocorreram durante a fase de clone para garantir que ele tenha os dados mais atualizados.

4. Seção e comprometimento crítico: o Shard doador entra em uma seção crítica em que as operações de gravação para o pedaço são brevemente bloqueadas, e a propriedade de pedaços é alterada atomicamente para o fragmento de destinatário.

5. Fase de exclusão: o Shard doador remove os documentos pertencentes ao pedaço migrado depois de confirmar que o destinatário cometeu com sucesso o pedaço.

O balanceador garante que apenas uma migração por fragmento ocorra em um momento para minimizar o impacto no desempenho do Shard. Ele pode executar várias migrações em paralelo em diferentes pares de shard se forem independentes.

Balancer automático

O balanceador é executado como um encadeamento de segundo plano no nó primário do servidor de configuração e monitora constantemente o balanço de dados do Shard. Ele rastreia o tamanho dos dados por pedaço para determinar se as migrações são necessárias de acordo com um limite de saldo configurável. Quando as diferenças no tamanho dos dados entre os fragmentos excedem esse limite, o balanceador inicia migrações.

O balanceador opera de maneira principalmente transparente para aplicações, mas pode ser temporariamente desativada para fins de manutenção ou ajuste. Ele também respeita as zonas configuradas no cluster, garantindo que os pedaços sejam migrados dentro dos limites apropriados da zona.

Comandos de migração manual

Enquanto o balanceador automatiza a migração de pedaços, o MongoDB também permite o controle manual usando comandos como 'MoveChunk` e `Moverange`. Esses comandos forçam a migração de pedaços ou pedaços específicos de um fragmento para outro.

- `MoveChunk` é usado para migrar um pedaço contendo um valor específico da chave do shard para um shard especificado. Isso é útil para migrações direcionadas para balanceamento de carga ou localidade de dados.

- `MoveRange` permite migrar uma faixa contígua de chaves de fragmento, úteis para estratégias de reequilíbrio de dados mais complexas.

Os administradores podem usar esses comandos para que os pedaços pré-divididos distribuam dados uniformemente antes da ingestão em massa ou para resolver falhas de migração causadas pelo equilíbrio das restrições das janelas.

lidando documentos e consistência órfãos

Durante e após a migração de pedaços, documentos órfãos (documentos não pertencem às faixas de pedaços atribuídas do doador) podem existir temporariamente no Shard doador até que sejam limpas.

O MongoDB garante consistência ao longo da migração aplicando operações em sequência e usando um mecanismo de coordenação que bloqueia gravações durante a seção crítica. Após a migração, a limpeza órfã é executada de forma assíncrona, evitando a interferência nas consultas contínuas.

Starting MongoDB 5.3, change streams do not generate events for updates to orphaned documents during migration, to maintain event stream accuracy.

Impacto no desempenho e operações

As migrações de chunk transportam sobrecarga, incluindo consumo de largura de banda de rede, CPU e E/S de disco, o que pode afetar o desempenho do cluster. MongoDB minimiza esse impacto por:

- Restringir a participação de um fragmento a uma migração por vez.

- Migrações na fila e permitir que as fases excluírem sobrecarregando sobrecarregando -se para uma descarga mais rápida.

- Usando opções de limitação para ajustar a simultaneidade da migração e escrever preocupação durante a migração.

Os dados de migração também afetam temporariamente as leituras secundárias que podem perder documentos durante a fase de limpeza órfã, portanto os aplicativos precisam considerar isso ao projetar suas consultas.

migração em cenários específicos

Em casos como os dados de migração entre zonas com faixas de tags, ou de configurações não estabelecidas para sharded, o MongoDB migra dados gradualmente com base nas faixas ou zonas de chave do shard atualizadas após a reconfiguração. Por exemplo, a remoção de intervalos de tags antigos e a criação de novos desencadeia a migração do Balancer para mover os dados de acordo.

Ao migrar clusters mongodb para soluções gerenciadas na nuvem ou entre clusters fragmentados, as ferramentas de migração geralmente executam a migração em termos de fragmento, copiando dados de shard individualmente, mantendo as distribuições de chaves do Shard.

Ferramentas e utilitários para migração

Os Serviços de Transmissão de Dados (DTS) e outras ferramentas de terceiros ajudam a migrar dados entre instâncias ou clusters do MongoDB, manipular o mapeamento de fragmentos, a consistência dos dados e as atualizações incrementais. Essas ferramentas geralmente suportam a migração de clusters não afastados para os sharded, atribuindo valores de chave de shard padrão aos dados de origem sem chaves de shard.

Resumo dos principais pontos

- O MongoDB divide os dados em pedaços distribuídos por fragmentos usando chaves de shard.

- O balanceador migra automaticamente pedaços para manter a distribuição de dados equilibrada.

- A migração envolve dados de clonagem, gravações de recuperação, transferência atômica e limpeza assíncrona.

- As migrações são restritas a um por fragmento para reduzir o impacto do sistema.

- Os comandos de migração manual fornecem controle administrativo para distribuição de pedaços.

- Os documentos órfãos são limpos de forma assíncrona após a migração.

- A migração afeta o desempenho e a consistência secundária de leitura temporariamente.

- A migração entre zonas ou alterações nos intervalos de chave do shard é tratada pela reconfiguração que aciona as migrações.

- As ferramentas de migração ajudam no movimento de dados entre clusters ou arquiteturas.

Esse mecanismo de migração garante que os clusters mongodb permaneçam equilibrados, escaláveis ​​e com desempenho à medida que os dados crescem e as configurações de cluster evoluem, fornecendo disponibilidade contínua com interrupção mínima para aplicações.