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 ela é compatível tanto com o MongoDB Atlas quanto com implantações no local. O MongoDB 8.0 inclui mudanças introduzidas nos MongoDB Rapid Releases 7.1, 7.2 e 7.3. Para ver as alterações introduzidas nessas Rapid Releases, consulte Alterações introduzidas em 7.X-Series Rapid Releases.
Para saber mais sobre as diferenças entre as Rapid Releases e versões principais, consulte Versões do MongoDB.
Atualizações de suporte da plataforma
A partir do MongoDB 8.0, as novas versões do Servidor MongoDB (principais e secundárias) suportam a versão secundária do sistema operacional (sistema operacional) definido 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 servidor MongoDB para oferecer suporte à próxima versão secundária do sistema operacional. Para obter detalhes, consulte Melhorias no suporte à plataforma MongoDB.
MongoDB 8. O 0 suporta 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 passa 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 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 banco 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 utilizar o operador $convert
para executar as seguintes conversões:
String values to binData values
valores binData para valores de string
MongoDB 8.0 também inclui uma nova expressão auxiliar, $toUUID
, que fornece sintaxe simplificada para converter strings em valores UUID .
$queryStats 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 Alterar Comportamento de Streams.
$rank
e $denseRank
comportamento
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
.
Fragmentação
A partir do MongoDB 8.0, você pode mover collections entre shards e collections não fragmentadas 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 fluxos de alteração
A partir do MongoDB 8.0, movePrimary
não invalida collections que tenham 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 Config Shard.
Novos comandos de banco de dados
Novos métodos de mongosh
Novas métricas do serverStatus
serverStatus
inclui os seguintes novos campos shardingStatistics
em sua saída:
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
.
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 aplicativo 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 utilizar 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 dados local. Isso aumenta a taxa de transferência de replicação para secundários.
Isso introduz uma alteração de ruptura 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:
Alterações gerais
Desempenho do desligamento
A partir do MongoDB 8.0, Bulk.insert()
e volumes 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 para armazenar dados do aplicativo, 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.
Estágio $lookup em transações com collections fragmentadas
A partir do MongoDB 8.0, você pode usar a etapa $lookup
dentro de uma transação enquanto segmenta uma collection fragmentada.
Melhorias na compactação
Compactação de background
A partir do MongoDB 8.0, você pode utilizar o novo comando autoCompact
para executar a compactação do background. 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.
Parameter Filtering
A partir do 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.
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.
Leia sobre as coleções com capas
A partir do MongoDB 8.0, você pode usar a read concern "snapshot"
em capped collections.
Operações de DDL
No MongoDB 8.0, se você adicionar ou remover um shard enquanto o cluster executa uma operação DDL (operação que modifica uma collection como reshardCollection
), qualquer operação que adicione ou remova um shard só será executada após a conclusão da operação DDL simultânea.
Tempo limite padrão para queries
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 individuais sejam concluídas.
Nova forma de query e configurações de query
MongoDB 8.0 introduz uma nova forma de query. A forma de query preexistente é renomeada como a 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 evitar usá-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
$querySettings
em um aggregation 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
explain
no campoexplain.queryShapeHash
analisador de banco de dados no campo
system.profile.queryShapeHash
Está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
.
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
.
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 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
As seguintes novas métricas do serverStatus
relatam informações sobre o uso do tcmalloc
:
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.
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 expressa
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.
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, insira as operações 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 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.
Segurança
Queries de intervalo de criptografia consultáveis
A partir do MongoDB 8.0, o 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 auditoria. 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 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.
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 fase de " podação de índice " do planejamento de query 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. |
Alterações introduzidas em 7.X-Series Rapid Releases
MongoDB 8.0 inclui alterações e recursos das seguintes versões do Rapid Release:
Procedimentos de atualização
Importante
Versão de compatibilidade de recursos
Para atualizar para o MongoDB 8.0 de um 7.0 sistema, o 7.0 sistema deve ter featureCompatibilityVersion
definido 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.