Notas de versão para MongoDB 8.0
Nesta página
Esta página descreve as alterações e as novas funcionalidades introduzidas no MongoDB 8.0.
O MongoDB 8.0 é uma versão principal, o que significa que ele recebe suporte tanto para o MongoDB Atlas quanto para sistemas on-premises. O MongoDB 8.0 inclui alterações introduzidas no MongoDB Rapid Releases 7.1, 7.2 e 7.3. Esta página descreve as alterações introduzidas nessas Rapid Releases e no MongoDB 8.0.
Para saber mais sobre as diferenças entre as Rapid Releases e versões principais, consulte Versões do MongoDB .
Lançamentos de patches
8.0.1 - 9 de outubro de 2024
Problemas corrigidos:
SERVIDOR-76883 Reduzir o número de registros de "função não existe" para usuários de origem externa
SERVER-82221 listCollections e listIndexes devem incluir namespaces pendentes de confirmação
SERVIDOR-94635 Tornar os parâmetros de atualização da sessão configuráveis
SERVIDOR-95244 As declarações upsert que resultam em uma inserção podem falhar com o tassert 9146500 quando o cliente se conecta diretamente ao shard
WT-13409 Um ret em __txn_checkpoint não é tratado
8.0.0 - 2 de outubro de 2024
O resto desta página descreve as alterações e novas funcionalidades introduzidas no MongoDB 8.0.
Atualizações de suporte da plataforma
A partir do MongoDB 8.0, as novas versões do MongoDB Server (principais e secundárias) suportam a versão secundária mínima do sistema operacional (OS) definida pelo fornecedor do sistema operacional. Depois que uma versão secundária do sistema operacional não é mais suportada pelo fornecedor do sistema operacional, o MongoDB atualiza o MongoDB Server para oferecer suporte à próxima versão secundária do sistema operacional. Para obter detalhes, consulte Melhorias no suporte à plataforma MongoDB.
O MongoDB 8.0 é compatível com as seguintes versões secundárias mínimas do sistema operacional:
Red hat enterprise Linux 8.8
Red hat enterprise Linux 9.3
SUSE Linux enterprise server 15 SP5
Amazon Linux 2023 versão 2023.3
Exploração madeireira
A partir do MongoDB 8.0, você pode configurar o analisador de banco de dados para registrar operações lentas com base no tempo que o MongoDB gasta trabalhando nessa operação, em vez da latência total da operação. Isso significa que fatores como a espera de travas e o controle de fluxo não afetam o fato de uma operação exceder o limite de operação lenta.
Essa alteração fornece as seguintes melhorias para geração de registros e análise de queries:
As queries lentas são registradas com mais precisão com base no tempo que o MongoDB gasta processando a query.
Ferramentas de análise de query, como o Query Profiler, o Performance Advisor e o Search Query Telemetry relatam operações lentas com base em
workingMillisem vez dedurationMillis. Esta alteração fornece uma visão mais precisa das queries problemáticas.Os registros de query lenta incluem uma métrica para o tempo enfileirado em tickets de execução,
queues.execution.totalTimeQueuedMicros. Essa métrica ajuda a identificar se uma operação é lenta devido ao tempo que leva para ser concluída ou ao tempo que passa esperando o início.
Para mais informações, consulte db.setProfilingLevel().
Database Profiler
Ao especificar um filtro para o analisador de profiler de banco de dados de dados, você pode registrar operações com base na nova métrica workingMillis . Você pode registrar operações com base em workingMillis e durationMillis e definir cada métrica para um limite diferente.
Agregação
Conversão de BinData
A partir do MongoDB 8.0, você pode usar o operador $convert para executar as seguintes conversões:
String values to binData values
valores binData para valores de string
O MongoDB 8.0 também inclui uma nova expressão assistente , $toUUID, que fornece sintaxe simplificada para converter strings em valores UUID .
$queryStats
A partir do MongoDB 7.1, o estágio $queryStats retorna estatísticas para queries registradas.
Melhorias no Change Stream
A partir do MongoDB 8.0, $queryStats melhora o rastreamento e as métricas de relatórios para change streams. Para mais informações, consulte $queryStats Change Streams .
Comportamento $rank e $denseRank
A partir do MongoDB 8.0, null e valores de campo ausentes nas operações $denseRank e $rank sortBy são tratados da mesma forma ao calcular classificações. Essa alteração torna o comportamento de denseRank e rank consistente com $sort.
Segurança
Queryable Encryption
A partir do MongoDB 8.0, A Queryable Encryption oferece suporte a queries de intervalo em campos criptografados usando os operadores $lt, $lte, $gt e $gte . Para obter detalhes, consulte Operações suportadas para Queryable Encryption. Para habilitar queries de intervalo em campos criptografados, consulte Criar um esquema de criptografia.
Esquema OCSF para mensagens de registro
A partir do MongoDB 8.0, você pode especificar o esquema OCSF para mensagens de registro de auditar . O esquema OCSF fornece registros em um formato padronizado compatível com processadores de registros.
Para definir o esquema usado para mensagens de registro, use a opção de arquivo de configuração auditLog.schema .
Para obter por exemplo , mensagens de registro no formato OCSF, consulte Mensagens de auditoria do esquema OCSF.
Fila de entrada
O MongoDB 8.0 introduz uma nova fila para o controle de entrada de entrada. As operações que aguardam a entrada da rede no banco de dados de dados entram na fila de entrada. Por padrão, a fila é irrestrita, o que significa que o MongoDB permite que todas as operações sejam executadas por esse estágio sem filas. Definir o máximo da fila para um valor específico permite enfileirar as operações nesse estágio se o número de operações atuais atingir o limite especificado.
Fragmentação
A partir do MongoDB 8.0, você pode mover collections não fragmentadas e mover collections não fragmentadas entre shards em clusters fragmentados.
Movendo uma coleção
A partir do MongoDB 8.0, você pode mover uma coleção não fragmentada para um fragmento diferente usando o comando moveCollection .
Para obter detalhes, consulte Coleções móveis. Para começar, consulte Mover uma coleção.
Movendo coleções que têm Change Streams
A partir do MongoDB 8.0, movePrimary não invalida as collections que têm change streams. Os change streams podem continuar lendo eventos de collections depois que as collections forem movidas para um novo shard.
Para obter detalhes, consulte Mover collections que têm Change Streams.
Desfragmentando uma collection
A partir do MongoDB 8.0, você pode desfragmentar collections fragmentadas existentes com o comando unshardCollection ou o método sh.unshardCollection() . Esta operação move todos os documentos na coleção para um shard especificado ou o shard com a menor quantidade de dados.
Para obter detalhes, consulte Collections não fragmentadas. Para começar, consulte Desfragmentar uma collection.
Config Shards
A partir do MongoDB 8.0, você pode configurar um servidor de configuração de configuração para armazenar os dados do aplicação , além dos metadados usuais do cluster fragmentado . Um nó mongod que oferece funcionalidade de servidor de servidor de configuração de shard é chamado de shard de configuração. Um nó do mongod que executa como um --configsvr autônomo sem funcionalidade de servidor de fragmento é chamado de servidor de configuração dedicado.
Para configurar um servidor de configuração dedicado para ser executado como um shard de configuração, execute o comando transitionFromDedicatedConfigServer .
Para configurar um shard de configuração para ser executado como um servidor de configuração dedicado, execute o comando transitionToDedicatedConfigServer .
Para obter detalhes, consulte Config Shard. Para começar, consulte Iniciar um cluster fragmentado com um shard de configuração. Para converter um conjunto de réplicas em um cluster fragmentado com um shard de configuração, consulte Converter um conjunto de réplicas em um cluster fragmentado com um servidor de configuração incorporado.
Novos comandos de banco de dados
Novos métodos de mongosh
Métricas do serverStatus
A partir do MongoDB 8.0, serverStatus inclui os seguintes novos campos shardingStatistics em sua saída:
shardingStatistics.countTransitionToDedicatedConfigServerStartedshardingStatistics.countTransitionToDedicatedConfigServerCompletedshardingStatistics.countTransitionFromDedicatedConfigServerCompleted
O MongoDB 7.1 inclui as seguintes novas estatísticas de fragmentação para migrações de chunks:
parte padrão por fragmento
A partir do MongoDB 7.2, quando você fragmenta uma collection vazia com uma chave de fragmento com hash, a operação cria uma parte por shard por padrão. Anteriormente, a operação criava dois chunks por padrão.
função directShardOperations
A partir do MongoDB 8.0, você pode usar a função directShardOperations para realizar operações de manutenção que exigem que você execute comandos diretamente em um shard.
Aviso
Executar comandos utilizando a função directShardOperations pode fazer com que seu cluster pare de funcionar corretamente e pode causar corrupção de dados. Use a função directShardOperations apenas para fins de manutenção ou sob a orientação do suporte do MongoDB . Quando terminar de executar as operações de manutenção, pare de usar a função directShardOperations .
Cursores de escape ativados para clusters fragmentados
A partir do MongoDB 7.1, mongos suporta cursores de escape quando a solicitação getMore de um cliente define o sinalizador exhaustAllowed . Isto pode melhorar o desempenho da consulta em clusters fragmentados quando o cliente recebe múltiplas respostas do servidor do banco de dados de dados para uma única solicitação.
Faixa de portas mongos
A partir do MongoDB 7.1, mongos aceita --port valores de [0, 65535]. Para mais informações, consulte --port.
Query com chave de shard parcial
A partir do MongoDB 7.1, findAndModify e deleteOne() podem usar uma chave de shard parcial para consultar uma collection fragmentada.
Aprimoramentos de refragmentação
O MongoDB 7.2 introduz melhorias significativas de desempenho nas operações de collection de refragmentação, reduzindo instantaneamente o tempo que a operação leva para ser executada.
Além disso, se a aplicação e o cluster atenderem aos requisitos e limitações necessários, você poderá refragmentar a collection na mesma chave usando o comando reshardCollection para redistribuir sua collection, que é muito mais rápido do que o procedimento de migração de intervalo alternativo.
As seguintes opções são adicionadas ao comando:
Campo | Descrição |
|---|---|
forceRedistribution | Habilita a refragmentação da mesma chave. |
Para obter exemplos, consulte Redistribuir dados para novos shards.
Backups autogerenciados de clusters fragmentados
A partir do MongoDB 7.1, os comandos fsync e fsyncUnlock podem executar operações de fsync em clusters fragmentados.
Ao executar no mongos com o campo lock definido como true, o comando fsync libera as gravações da camada de armazenamento para o disco e bloqueia cada shard, evitando gravações adicionais. O comando fsyncUnlock pode então ser utilizado para desbloquear o cluster.
Esse recurso permite backups autogerenciados de clusters fragmentados usando mongodump.
Comportamento de upsert do UpdateOne em coleções fragmentadas
A partir do MongoDB 7.1, ao usar updateOne() com upsert: true em uma coleção fragmentada, você não precisa incluir a chave de shard completa no filtro.
Estágio $lookup em transações com collections fragmentadas
A partir do MongoDB 8.0, você pode usar o estágio $lookup dentro de uma transação enquanto direciona uma collection fragmentada.
Replicação
Preocupação majoritária com gravação
A partir do MongoDB 8.0, as operações de gravação que usam a preocupação de gravação "majority" retornam uma confirmação quando a maioria dos membros do conjunto de réplicas tiver escrito a entrada de oplog para a alteração. Isso melhora o desempenho de "majority" gravações. Em versões anteriores, essas operações aguardavam e retornavam uma confirmação após a maioria dos membros do conjunto de réplicas aplicar a alteração.
Se o aplicação ler de um secundário imediatamente após receber uma confirmação de uma operação de gravação { w: "majority" } (sem uma sessão causalmente consistente ), a query poderá retornar resultados que não incluam alterações da gravação.
Novas métricas replSetGetStatus
A partir do MongoDB 8.0, as seguintes métricas estão disponíveis ao usar o comando replSetGetStatus :
Buffers de oplog
A partir do MongoDB 8.0, os secundários gravam e aplicam entradas de oplog para cada lote em paralelo. Um thread de gravador lê novas entradas do primário e as grava no oplog local. Um thread aplicador aplica de forma assíncrona essas alterações ao banco de banco de dados local . Isso aumenta a taxa de transferência de replicação para secundários.
Isso introduz uma alteração interruptiva para metrics.repl.buffer, pois agora fornece métricas em dois buffers em vez de um.
O MongoDB 8.0 descontinua as seguintes métricas de status do servidor :
O MongoDB 8.0 adiciona as seguintes métricas de status do servidor :
TCMalloc atualizado
A partir do MongoDB 8.0, O MongoDB usa uma versão atualizada do TCMalloc que usa caches por CPU, em vez de caches por thread, para reduzir a fragmentação da memória e tornar seu banco de dados de dados mais resiliente a cargas de trabalho de alto estresse.
A nova versão do TCMalloc afeta diretamente as recomendações de produção anteriores para Transparent Huge Pages. Para saber mais, consulte Otimização de desempenho do TCMalloc para um sistema autogerenciado.
Métricas do serverStatus
A partir do MongoDB 8.0, as seguintes novas serverStatus métricas relatam informações sobre o uso tcmalloc :
Alterações gerais
Desempenho do desligamento
A partir do MongoDB 8.0, Bulk.insert() e cargas de trabalho de ingestão de dados podem ter um desempenho melhor. No entanto, desligar o MongoDB imediatamente após a execução dessas cargas de trabalho pode levar mais tempo devido aos dados extras que estão sendo liberados para o disco.
Armazene dados de aplicativos em shards de configuração
A partir do MongoDB 8.0, você pode configurar um servidor de configuração de configuração para armazenar dados do aplicação , além dos metadados usuais do cluster fragmentado . O servidor de configuração é então conhecido como shard de configuração. Para obter detalhes, consulte Config Shards.
Melhorias na compactação
A partir do MongoDB 7.3, o comando compact inclui uma nova opção freeSpaceTargetMB para especificar a quantidade mínima de espaço de armazenamento, em megabytes, que deve ser recuperável para que a compactação continue.
Compactação de background
A partir do MongoDB 8.0, você pode usar o novo comando autoCompact para executar a compactação em segundo plano. Se ativado, o servidor tenta manter o espaço livre dentro de cada coleção e índice abaixo do valor freeSpaceTargetMB especificado.
Opção dryRun
Se ativado, o comando compact retorna uma estimativa de quanto espaço, em bytes, a compactação pode recuperar da collection direcionada. Se você executar compact com dryRun definido como true, o MongoDB retornará apenas o valor estimado e não executará nenhum tipo de compactação.
Operações DDL simultâneas
A partir do MongoDB 7.1, quando você executa várias operações de DDL que têm como alvo diferentes collections do mesmo banco de dados de dados, o MongoDB executa essas operações simultaneamente.
Esta alteração adiciona dois novos tipos ao campo serverStatus locks e saída currentOp.locks :
DDLDatabaseDDLCollection
Validação de banco de dados em queries de agregação mongos
A partir do MongoDB 7.2, as query do aggregation pipeline que tentam usar reconhecimento de data center inexistentes em implantações do mongos retornam erros de validação.
Nas versões anteriores, essas query de agregação retornam cursor vazios.
Operações de DDL
No MongoDB 8.0, se você adicionar ou remover um fragmento enquanto o cluster executa uma operação DDL (operação que modifica uma coleção como reshardCollection), qualquer operação que adicione ou remova um fragmento só será executada após a conclusão da operação DDL simultânea.
Códigos de erro para exceder o limite de tamanho do pipeline
A partir do MongoDB 7.1, um comando de aggregation lançará um erro quando um pipeline exceder o limite de estágio do pipeline. Para obter mais detalhes, consulte Restrições do Número de Estágios.
O campo getField suporta todas as strings
A partir do MongoDB 7.2, você pode especificar qualquer expressão válida que se resolva em uma string para a entrada field do operador $getField . Em versões anteriores, o field aceita somente constantes de string.
Construções de índice aprimoradas
A partir do MongoDB 7.1, as compilações de índice são aprimoradas com relatórios de erros mais rápidos e maior resiliência a falhas. Você também pode definir o espaço mínimo em disco disponível necessário para compilações de índice usando o novo parâmetro indexBuildMinAvailableDiskSpaceMB , que interrompe as compilações de índice se o espaço em disco estiver muito baixo.
As seguintes novas métricas de criação de índice foram adicionadas:
Para obter detalhes completos, consulte Index Builds.
Novos parâmetros
Parâmetro auditConfig
O MongoDB 7.1 adiciona o parâmetro de cluster auditConfig , que contém informações sobre configurações de auditar de instâncias de servidor mongod e mongos .
Parâmetro defaultMaxTimeMS
A partir do MongoDB 8.0, você pode usar o parâmetro de cluster defaultMaxTimeMS para especificar um limite de tempo padrão para que as operações de leitura individual sejam concluídas.
Parâmetro indexBuildMinAvailableDiskspaceMB
O MongoDB 7.1 adiciona o parâmetro indexBuildMinAvailableDiskSpaceMB , que permite definir o espaço mínimo em disco disponível necessário para a criação de índices.
tcmallocEnableBackgroundThread Parameter
A partir do MongoDB 8.0, o tcmallocEnableBackgroundThread está habilitado por padrão. Isso permite que o MongoDB libere periodicamente a memória de volta para o sistema operacional.
Novo comando de gravação em massa
A partir do MongoDB 8.0, você pode usar o novo comando bulkWrite para executar muitas operações de inserção, atualização e exclusão em várias collections em uma única solicitação. O método db.collection.bulkWrite() existente permite somente a você modificar uma coleção em uma solicitação.
Nova forma de query e configurações de query
O MongoDB 8.0 introduz uma nova forma de query. A forma de query preexistente é renomeada como forma de query do cache do plano.
A partir do MongoDB 8.0, você pode adicionar configurações de query para a nova forma de query. O otimizador de query usa as configurações de query como uma entrada adicional durante o planejamento de query, o que afeta o plano selecionado para executar uma query que tenha uma forma de query correspondente.
As configurações de query melhoraram a funcionalidade em comparação com os filtros de índice. Os filtros de índice também ficaram obsoletos a partir do MongoDB 8.0, e você deve evitá-los.
Para adicionar configurações de query, use o comando
setQuerySettings.Para excluir configurações de query, use o comando
removeQuerySettings.Para recuperar as configurações de query, use um estágio
$querySettingsem um agregação pipeline.Para bloquear uma forma de query, consulte filtros de rejeitar operação.
A partir do MongoDB 8.0, queryShapeHash está incluído na seguinte saída:
Comando
explainno campoexplain.queryShapeHashanalisador de profiler de banco de dados de dados no campo
system.profile.queryShapeHashEstágio de pipeline de agregação $currentOp no campo
$currentOp.queryShapeHash
A partir do MongoDB 8.0, o campo queryHash pré-existente é renomeado para planCacheShapeHash. Se você estiver usando uma versão anterior do MongoDB , verá queryHash em vez de planCacheShapeHash.
Parameter Filtering
Iniciando no MongoDB 8.0, o comando getParameter aceita um campo setAt . Você pode usar esse campo para filtrar o documento de retorno allParameters: true para mostrar apenas os parâmetros que você pode definir na inicialização ou no tempo de execução.
Leia sobre as coleções com capas
A partir do MongoDB 8.0, você pode usar a preocupação de leitura "snapshot" em coletas limitadas .
Alteração de saída doserverStatus
A partir do MongoDB 7.1, a saída de comando serverStatus inclui as seguintes novas métricas:
A partir do MongoDB 7.2, a saída de comando serverStatus inclui as seguintes novas métricas:
A partir do MongoDB 7.3, a saída de comando serverStatus inclui as seguintes novas métricas:
A partir do MongoDB 8.0, a saída de comando serverStatus inclui as seguintes novas métricas:
Suporte de classificação para updateOne
A partir do MongoDB 8.0, o método updateOne() suporta uma opção sort . Isso controla como o MongoDB ordena o documento antes de selecionar o documento para receber a atualização.
As versões anteriores utilizam os métodos findAndModify() e findOneAndUpdate() para atualizar o primeiro documento em uma ordem de classificação especificada pelo usuário. O suporte para gravações repetidas exige que esses métodos copiem o documento inteiro para uma coleção lateral especial para cada nó, que é uma operação mais cara do que o método updateOne() com a nova opção sort .
Especificar dicas de índice de query para comandos distintos
A partir do MongoDB 7.1, o campo hint está disponível no comando distinct , permitindo a você especificar o índice da query.
TTL Indexes
A partir do MongoDB 7.1, você pode criar índices TTL em capped collections.
Planejamento e execução de queries
Processamento de blocos
A partir da versão 8.0, O MongoDB pode executar determinadas queries de séries temporais usando processamento de blocos. Essa melhoria de desempenho processa as queries em "blocos" de dados, em vez de valores individuais. O processamento de blocos melhora a velocidade de execução da query e a taxa de transferência ao trabalhar com coleções de séries temporais.
Para ver se sua query de série temporal usa processamento de blocos, marque o campo explain.queryPlanner.winningPlan.slotBasedPlan.stages na saída do plano de explicação.
Para saber mais, consulte Processamento de blocos.
Estágios de query Express
A partir do MongoDB 8.0, um conjunto limitado de queries (incluindo _id correspondências de igualdade) ignora o planejamento e a execução de queries regulares. Em vez disso, essas queries usam um plano de varredura de índice otimizado que consiste em um destes estágios do plano:
EXPRESS_CLUSTERED_IXSCANEXPRESS_DELETEEXPRESS_IXSCANEXPRESS_UPDATE
Para obter mais informações sobre planos de query, consulte Explicar resultados.
Saída do plano de query rejeitada
A partir do MongoDB 8.0, os planos de query rejeitados contêm apenas a parte find da query. Em versões anteriores, os planos rejeitados podem conter estágios de agregação como $group. Esses estágios de agregação não são usados pelo planejador de query para escolher o plano vencedor, portanto, o campo rejectedPlans contém apenas a parte da query que foi usada para escolher o plano vencedor.
Essa alteração também garante que os executionStats para planos rejeitados sejam diferentes de zero. Como resultado, agora você pode ver estatísticas como quantos documentos ou chaves um plano rejeitado examinou.
Para obter mais informações sobre planos de query rejeitados, consulte explain.queryPlanner.rejectedPlans.
Operações de inserção de vários documentos em lote
A partir do MongoDB 8.0, as operações de inserção para transações com vários documentos não produzem mais entradas oplog individuais. Em vez disso, inserções de vários documentos são agrupadas como uma única entrada. O evento de fluxo de alteração insert para cada documento tem o mesmo clusterTime.
Essa alteração aumenta o desempenho de operações de inserção de vários documentos e elimina possíveis atrasos de atraso de replicação causados por várias gravações oplog .
Os provedores de identidade da OIDC podem compartilhar um emissor
A partir do MongoDB 8.0, quando vários fornecedores de identidade (IDP) são definidos, o parâmetro oidcIdentityProviders aceita valores issuer duplicados, desde que o valor audience seja exclusivo para cada emissor. Isso também está disponível nas versões 7.3 e 7.0.
Namespaces em Subpipelines
A partir do MongoDB 8.0, os namespaces em subpipelines dentro $lookup e $unionWith são validados para garantir o uso correto dos campos from e coll .
Para obter detalhes, consulte $lookup subpipelines e $unionWith subpipelines.
Tempo de otimização do planejador de queries
O método explain() agora retorna informações sobre o tempo de otimização do planejador de query. O status queryPlanner.optimizationTimeMillis mostra o tempo em milissegundos que o planejador de query gastou em otimizações.
Problemas conhecidos
Esta seção descreve problemas conhecidos no MongoDB 8.0 e seu status de resolução.
Na versão | Emitir | Status |
|---|---|---|
8.0.0 | SERVIDOR-94741: Quando vários índices são utilizáveis por $or queries que incluem $and cláusulas de nível superior (incluindo $and cláusulas implícitas), a query pode usar índices menos eficientes porque os índices mais eficientes foram removidos incorretamente da consideração durante a nova "index podando" fase do planejamento de consulta no MongoDB 8.0. | Não resolvido. Planejado para ser mitigado em 8.0.1 desativando o recurso de remoção de índice no SERVER-94738. |
8.0.0 | SERVIDOR-95244: As operações de upsert em clusters de um shard podem falhar com mais frequência quando todas as condições a seguir são verdadeiras:
O processo recomendado para a transição para um cluster fragmentado requer a mudança de clientes para se conectar a roteadores | Esse problema está planejado para ser corrigido em 8.0.1. |
Procedimentos de atualização
Importante
Versão de compatibilidade de recursos
Para atualizar para o MongoDB 8.0 a partir de uma implantação do 7.0 , a implantação do 7.0 deve ter featureCompatibilityVersion configurado como 7.0. Para verificar a versão:
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
Para atualizar para o MongoDB 8.0, consulte as instruções de atualização específicas para o MongoDB deployment:
Caso você precise de orientação ao atualizar para a versão 8.0, os serviços profissionais do MongoDB oferecem suporte à atualização de versões principais, o que ajuda a garantir uma transição tranquila e sem interrupções para seu aplicativo do MongoDB. Para saber mais, consulte a página Consultoria do MongoDB.
Download
Para baixar o MongoDB 8.0, acesse a Central de downloads do MongoDB.