Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/

Notas de versão para MongoDB 8.0

Nesta página

  • Lançamentos de patches
  • Atualizações de suporte da plataforma
  • Exploração madeireira
  • Agregação
  • Segurança
  • Fragmentação
  • Replicação
  • TCMalloc atualizado
  • Alterações gerais
  • Problemas conhecidos
  • Procedimentos de atualização
  • Download

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 .

Importante

A invalidação inadequada de bytes nulos pode levar a leituras excessivas de buffer no MongoDB Server

No MongoDB 8.0 antes de 8.0.3, um usuário autorizado pode desencadear falhas ou receber o conteúdo de leituras excessivas de buffer da memória do servidor emitindo solicitações especialmente criadas que constroem BSON malformado no MongoDB Server.

Esse problema afeta as versões do MongoDB Server :

  • 5.0.0 - 5.0.29

  • 6.0.0 - 6.0.18

  • 7.0.0 - 7.0.14

  • 8.0.0 - 8.0.2

Problemas corrigidos:

  • SERVIDOR- A96419 minimização inadequada de bytes nulos pode levar a leituras excessivas de buffer no MongoDB Server

  • Todos os problemas do JIRA foram encerrados em 8.0.3

  • 8.0.3 Registro de alterações

Problemas corrigidos:

O resto desta página descreve as alterações e novas funcionalidades introduzidas no MongoDB 8.0.

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

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 workingMillis em vez de durationMillis. 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().

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.

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 .

A partir do MongoDB 7.1, o estágio $queryStats retorna estatísticas para queries registradas.

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 .

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.

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.

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.

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.

A partir do MongoDB 8.0, você pode mover collections não fragmentadas e mover collections não fragmentadas entre shards em clusters fragmentados.

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.

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.

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.

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.

A partir do MongoDB 8.0, serverStatus inclui os seguintes novos campos shardingStatistics em sua saída:

O MongoDB 7.1 inclui as seguintes novas estatísticas de fragmentação para migrações de chunks:

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.

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 .

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.

A partir do MongoDB 7.1, mongos aceita --port valores de [0, 65535]. Para mais informações, consulte --port.

A partir do MongoDB 7.1, findAndModify e deleteOne() podem usar uma chave de shard parcial para consultar uma collection fragmentada.

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.

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.

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.

A partir do MongoDB 8.0, você pode usar o estágio $lookup dentro de uma transação enquanto direciona uma collection fragmentada.

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.

A partir do MongoDB 8.0, as seguintes métricas estão disponíveis ao usar o comando replSetGetStatus :

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 :

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.

A partir do MongoDB 8.0, as seguintes novas serverStatus métricas relatam informações sobre o uso tcmalloc :

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.

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.

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.

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.

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.

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 :

  • DDLDatabase

  • DDLCollection

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.

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.

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.

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.

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.

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 .

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.

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.

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.

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.

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.

A partir do MongoDB 8.0, queryShapeHash está incluído na seguinte saída:

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.

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.

A partir do MongoDB 8.0, você pode usar a preocupação de leitura "snapshot" em coletas limitadas .

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:

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 .

A partir do MongoDB 7.1, o campo hint está disponível no comando distinct , permitindo a você especificar o índice da query.

A partir do MongoDB 7.1, você pode criar índices TTL em capped collections.

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.

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_IXSCAN

  • EXPRESS_DELETE

  • EXPRESS_IXSCAN

  • EXPRESS_UPDATE

Para obter mais informações sobre planos de query, consulte Explicar resultados.

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.

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 .

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.

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.

O explain() método agora retorna informações sobre o tempo de otimização do planejador de query. O status mostra o tempo em milissegundos que o planejador de query gastou em queryPlanner.optimizationTimeMillis otimizações.

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:

  • A operação é emitida diretamente para um fragmento e não para mongos.

  • A operação upsert é exclusivamente uma inserção.

  • O namespace não está recebendo operações de roteadores mongos .

  • O namespace não está recebendo nenhuma outra operação.

O processo recomendado para a transição para um cluster fragmentado requer a mudança de clientes para se conectar a roteadores mongos . As gravações emitidas para roteadores mongos não são afetadas.

Esse problema está planejado para ser corrigido em 8.0.1.

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.

Para baixar o MongoDB 8.0, acesse a Central de downloads do MongoDB.

Voltar

Notas de versão