O MongoDB 4.4 atingiu o fim da vida útil (End of Life, EOL) em fevereiro de 2024. Continuar executando uma versão em EOL significa não receber mais patches de segurança, correções de bugs nem suporte. Além disso, o ApsaraDB for MongoDB documentou bugs específicos de kernel e riscos operacionais nas versões 4.4 e anteriores — alguns classificados com severidade Alta — que só se resolvem com a atualização.
Atualize para o MongoDB 5.0, 6.0, 7.0 ou 8.0. Para consultar as datas do ciclo de vida das versões, veja Lifecycle Schedules.
Riscos em versões anteriores
A equipe do ApsaraDB for MongoDB identificou os riscos a seguir com base na experiência de longo prazo em operações de bancos de dados na cloud.
Documentos órfãos causam inconsistência de dados durante a migração
Versões afetadas: instâncias de sharded cluster executando MongoDB 4.2 ou posterior
Versão da correção: MongoDB 4.4 ou posterior
Depois que um chunk migra de um shard de origem para um shard de destino, o shard de origem retém o chunk temporariamente antes da exclusão. Interrupções na migração deixam documentos órfãos para trás. Documentos órfãos não afetam as requisições nos nós mongos, pois essas requisições são verificadas pelos dados de roteamento dos nós ConfigServer. No entanto, documentos órfãos se acumulam e causam inconsistência de dados em migrações subsequentes.
O MongoDB 4.4 introduziu a migração de chunks com autorrecuperação e a limpeza automática de documentos órfãos. Se os nós falharem no meio de uma migração, o MongoDB retoma o processo automaticamente — sem necessidade de executar cleanupOrphaned manualmente. Execute o comando apenas para confirmar que as threads de limpeza em segundo plano estão ativas.
Para mais detalhes, veja cleanupOrphaned.
O comando compact bloqueia leituras e gravações
Versões afetadas: todas as arquiteturas executando MongoDB 4.2 ou anterior
Versão da correção: MongoDB 4.4 ou posterior
Executar compact para desfragmentar um disco no MongoDB 4.2 ou anterior bloqueia todas as operações de leitura e gravação durante toda a execução. A operação não pode ser interrompida, portanto a única forma de recuperação é reiniciar a instância, o que afeta a continuidade dos negócios.
O MongoDB 4.4 otimizou o comportamento de bloqueio do compact para que operações CRUD não sejam bloqueadas. Apenas algumas operações DDL — createIndex e dropIndex — sofrem impacto por pouco tempo. Agende as execuções de compact fora da janela de manutenção.
Para desfragmentar um disco, recomendamos usar o recurso storage analysis do ApsaraDB for MongoDB.
Para mais detalhes, veja Defragment the disks of an instance e compact blocking.
O comando compact faz os nós entrarem no estado RECOVERING
Versões afetadas: todas as arquiteturas com versão principal MongoDB 4.2 ou anterior e versão secundária anterior à 4.2.18
Versão da correção: MongoDB 4.4 ou posterior
Nas versões afetadas, executar compact faz com que os nós mongos entrem no estado RECOVERING. Se os nós permanecerem nesse estado por tempo suficiente, o componente de ativação do ApsaraDB for MongoDB os considera não íntegros e dispara uma reconstrução, causando indisponibilidade não planejada.
A partir do MongoDB 4.2.18, os nós mongos não entram mais no estado RECOVERING após a execução do compact, evitando tanto nós indisponíveis quanto fluxos inesperados de reconstrução.
Para desfragmentar um disco, recomendamos usar o recurso storage analysis do ApsaraDB for MongoDB.
Para mais detalhes, veja Defragment the disks of an instance e compact RECOVERING.
Backups físicos em nós ocultos consomem espaço em disco excessivo
Versões afetadas: todas as arquiteturas executando MongoDB 4.2 ou anterior que usam discos locais
Versão da correção: MongoDB 5.0 ou posterior (discos em cloud)
O mecanismo de backup físico em instâncias com disco local faz com que os arquivos de disco cresçam continuamente durante os uploads de backup. Grandes volumes acumulados de arquivos consomem espaço significativo em disco e disparam alertas incorretos de uso de disco durante falhas ou switchovers de nós.
Instâncias com disco em cloud combinam backup físico com snapshots de disco, o que reduz o tempo necessário para manter os checkpoints de backup do WiredTiger (WT) e resolve o inchaço de espaço em disco em nós ocultos. Para instâncias de replica set com mais de 2 TB de dados, use snapshot backup para evitar os longos tempos de backup, as altas taxas de falha e os conflitos de operações de O&M típicos de backups físicos em disco local.
Dados de roteamento residuais quebram bancos de dados recriados com o mesmo nome
Versões afetadas: instâncias de sharded cluster executando MongoDB 4.4 ou anterior
Versão da correção: MongoDB 5.0 ou posterior
Quando você remove um banco de dados com dropDatabase em um sharded cluster e depois recria um banco de dados com o mesmo nome, dados residuais de roteamento no nó ConfigServer fazem operações de leitura e gravação falharem.
No MongoDB 4.2 ou anterior, você precisa executar dropDatabase repetidamente e, em seguida, executar flushRouterConfig em todos os nós mongos para descarregar os dados de roteamento — caso contrário, os dados residuais degradam o desempenho.
O MongoDB 5.0 otimizou o tratamento dos dados de roteamento pelo dropDatabase, de modo que os dados de roteamento sejam limpos automaticamente, eliminando essa necessidade de limpeza manual.
Para mais detalhes, veja dropDatabase e flushRouterConfig.
O write concern padrão {w:1} causa falhas de sincronização de dados em nós secundários
Versões afetadas: todas as arquiteturas executando versões anteriores ao MongoDB 5.0
Versão da correção: MongoDB 5.0 ou posterior
Com o write concern padrão de {w:1}, dados gravados rapidamente no nó primário podem chegar apenas parcialmente aos nós secundários, fazendo-os entrar no estado RECOVERING. Isso degrada a disponibilidade da instância, quebra cargas de trabalho com read/write splitting e impede backups incrementais e restauração para um ponto no tempo.
O MongoDB 5.0 mudou o write concern padrão de {w:1} para {w:"majority"}. Os dados só ficam disponíveis para consulta após a maioria dos membros do replica set confirmar a gravação, o que aumenta a confiabilidade dos dados com uma leve perda de desempenho. Em cenários de alta taxa de gravação em que você aceita o comportamento anterior, defina o write concern novamente como {w:1}.
Para mais detalhes, veja Default write concern e setDefaultRWConcern.
O balancer rebalanceia dados de forma lenta demais para dar suporte a scale-out
Versões afetadas: todas as arquiteturas executando versões anteriores ao MongoDB 5.0
Versão da correção: MongoDB 5.0 ou posterior
O balancer não consegue migrar chunks com rapidez suficiente para rebalancear os dados durante eventos de scale-out, o que degrada o desempenho, já que os dados permanecem distribuídos de forma desigual entre os shards.
O MongoDB 5.0 adicionou os parâmetros chunkMigrationConcurrency e balancerMigrationsThrottlingMs para que você ajuste a concorrência e o throughput das migrações do balancer conforme a sua carga de trabalho.
Se a sua instância já está no MongoDB 5.0, mas esses parâmetros não estão disponíveis, atualize para uma versão secundária mais recente. Veja Update the minor version of an instance.
Para mais detalhes, veja chunkMigrationConcurrency e balancerMigrationsThrottlingMs.
Balanceamento baseado em contagem de chunks causa desbalanceamento de carga em sharded clusters
Versões afetadas: todas as arquiteturas com versão principal MongoDB 5.0 ou anterior e versão secundária anterior à 6.0.3
Versão da correção: MongoDB 6.0 ou posterior
O balancer distribui os dados com base na contagem de chunks, e não no volume de dados. Quando existem jumbo chunks ou chunks vazios — ou quando um subconjunto de dados recebe tráfego desproporcionalmente alto —, os chunks parecem balanceados por contagem, mas os shards carregam cargas desiguais.
O MongoDB 6.0.3 mudou o balancer para distribuir os dados com base na diferença de volume de dados entre os shards, em vez da contagem de chunks. Isso resolve o desbalanceamento de carga causado por jumbo chunks, chunks vazios e padrões de dados quentes.
Para mais detalhes, veja Changes to the balancer in MongoDB 6.0.3.
Após a atualização, pode ser que os chunks entre shards já não estejam balanceados ou que cada shard passe a conter apenas um chunk. Esse é o comportamento esperado do novo balancer — os seus dados continuam uniformemente distribuídos. Para mais detalhes, veja Imbalanced chunk count across shards after a MongoDB upgrade.
Outras questões de kernel
A tabela a seguir lista outras questões de kernel identificadas pela equipe do ApsaraDB for MongoDB em versões anteriores do MongoDB.
|
Versão |
Problema |
Nível de risco |
Gatilho e descrição |
|
MongoDB 3.4 |
Médio |
Gatilho: read/write splitting está ativado. Problema: bloqueios globais são adquiridos quando nós secundários reproduzem oplogs, causando requisições lentas. |
|
|
MongoDB 4.0 |
Baixo |
Gatilho: a contagem de conexões do servidor aumenta significativamente. Problema: sessões insuficientes disparam asserções, causando falhas e switchovers de nós mongos. |
|
|
MongoDB 3.6–4.2 |
Baixo |
Gatilho: ocasional. Problema: erro |
|
|
MongoDB 4,2 ou anterior |
Baixo |
Gatilho: ocasional; relacionado a |
|
|
MongoDB 4.0–4.2 |
Baixo |
Gatilho: ocasional. Problema: o servidor não consegue distinguir transações de retryable writes, causando falhas em requisições. |
|
|
MongoDB 4.0–4.4 |
Alto |
Gatilho: transações de longa duração. Problema: o cache write-through não consegue fazer eviction, as linhas de cache sujas ultrapassam 20% e as threads de limpeza de transações travam — causando aumento significativo de latência nas requisições e degradação de desempenho. |
|
|
MongoDB 3.6–4.4 |
Alto |
Gatilho: nós ConfigServer não passaram por switchover em 90 dias. Problema: falhas na geração de chaves Hash-based Message Authentication Code (HMAC) nos nós ConfigServer fazem os nós mongos travarem e não conseguirem se recuperar automaticamente. |
|
|
MongoDB 4.0–4.4 |
Médio |
Gatilho: ocasional. Problema: um erro de asserção do opContext faz o mongod travar e dispara um switchover. |
|
|
MongoDB 4.4 ou anterior |
Alto |
Gatilho: operações DDL são registradas em oplogs durante a criação de índices em segundo plano em nós secundários. Problema: operações DDL ficam bloqueadas e nós secundários falham. |
|
|
MongoDB 4.4 ou anterior |
Médio |
Gatilho: reinício de nó ou inicialização de sincronização de dados. Problema: problemas de ordenação temporal no history store do WiredTiger disparam um erro de asserção do WT, fazendo o mongod travar. |
|
|
MongoDB 4.2–4.4 |
Alto |
Gatilho: read/write splitting está ativado e a carga dos nós secundários é alta. Problema: contenção de mutex de thread POSIX esgota os read tickets nos nós secundários, degradando o desempenho. |
|
|
MongoDB 4.2–4.4 |
Médio |
Gatilho: a aplicação chama |
|
|
MongoDB 6.0 ou anterior |
Alto |
Gatilho: erro de out-of-memory (OOM) durante a criação de índices. Problema: o mongod reinicia repetidamente e não consegue se recuperar. Se dois nós de replica set entrarem nesse estado, a instância se torna indisponível. |
|
|
MongoDB 6.0 ou anterior |
Baixo |
Gatilho: grandes quantidades de documentos expirados após a criação de índices Time to Live (TTL) ou modificação dos tempos de expiração. Problema: as threads TTL em segundo plano ficam travadas e não se recuperam, fazendo o recurso TTL parar de funcionar. |
Novos recursos em versões mais recentes
| Versão | Recurso | Descrição |
|---|---|---|
| MongoDB 5.0 | Time series collections | Armazenamento e consulta eficientes de dados de séries temporais para cenários de Internet of Vehicles (IoV) e Internet of Things (IoT). |
| Consultas de snapshot de longa duração | Leia snapshots históricos sem afetar as operações em andamento. | |
| Versioned API | Desacopla o ciclo de vida da aplicação do ciclo de vida do banco de dados. As aplicações permanecem totalmente compatíveis entre atualizações de versão do banco de dados — sem necessidade de ajustes de compatibilidade. | |
| MongoDB 6.0 | Change streams | Pre-change views passam a estar disponíveis. A eficiência de execução e a utilização de recursos melhoraram. Atualizações de documentos órfãos podem ser filtradas. Mais eventos de mudança DDL têm suporte, o que aprimora o suporte a Change Data Capture (CDC). |
| Consultas JOIN em sharded clusters | Instâncias de sharded cluster suportam os operadores $lookup e $graphLookup para consultas JOIN, com desempenho de operadores aprimorado. |
|
| Desfragmentação automática em sharded clusters | Use configureCollectionBalancing para especificar tamanhos de chunk por shard e ativar a desfragmentação automática — sem necessidade de executar compact manualmente em sharded clusters. |
|
| Melhorias em time series collections | Suporte a sharding, compressão colunar para reduzir o uso de armazenamento, índices secundários e compostos para desempenho de leitura, índices geoespaciais para dados espaço-temporais e ordenação otimizada de séries temporais. | |
Comando compact aprimorado |
O compact foi totalmente otimizado no WiredTiger, com desempenho significativamente melhor e menos falhas causadas por eviction. |
|
| MongoDB 7.0 | Análise de shard key | Analise resultados de consultas amostradas para avaliar se a shard key de uma coleção é ideal. Use isso para configurar esquemas e shard keys de forma mais eficiente. |
| Queryable encryption | Criptografa dados sensíveis durante todo o seu ciclo de vida — em trânsito, em repouso, em uso, em logs e em backups. Os dados são descriptografados apenas no cliente, o que reduz significativamente os riscos de vazamento por roubo. | |
| Verificação de consistência de metadados | Detecta automaticamente inconsistências de metadados e índices após o encerramento de uma janela de manutenção ou após exceções como erros OOM ou failovers. | |
| Eventos de mudança grandes em change streams | O operador $changeStreamSplitLargeEvent divide eventos de mudança maiores que 16 MB, resolvendo a limitação de versões anteriores em que eventos grandes causavam falhas nas change streams. |
|
| Throttling dinâmico no WiredTiger | Ajusta dinamicamente a concorrência de transações do WiredTiger (padrão: 128) para evitar falhas do banco de dados por acúmulo de requisições após exceções. | |
| MongoDB 8.0 | TCMalloc avançado | Usa caches por CPU em vez de caches por thread para reduzir a fragmentação de memória e lidar com cargas mais pesadas. Uma thread em segundo plano libera memória para o sistema operacional a cada segundo. |
| Desempenho de replicação otimizado | Com o write concern definido como majority, o MongoDB retorna após os oplogs serem gravados na maioria dos membros do replica set, em vez de esperar que a alteração seja aplicada — o que melhora o throughput de gravação. Os nós secundários também gravam e aplicam batches de oplog em paralelo: uma thread Writer lê do primário e grava no oplog local, enquanto uma thread Applier aplica as alterações ao banco de dados local de forma assíncrona. |
|
| Resharding otimizado | Desempenho aprimorado de reshardCollection para alterar a shard key e a distribuição de dados de uma coleção. |