Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/
Notas de versão

Notas de versão para MongoDB 5.0

Nesta página

  • Lançamentos de patches
  • Coleções de Time Series
  • Agregação
  • Auditoria
  • Capped collections
  • Fluxos de alterações
  • Indexes
  • Comandos removidos
  • Conjuntos de réplicas
  • Segurança
  • Clusters fragmentados
  • Mudanças no shell
  • Snapshots
  • Transações
  • Alterações de nomenclatura
  • Alterações gerais
  • Considerações de desempenho
  • Suporte a plataformas
  • Alterações que afetam a compatibilidade
  • Procedimentos de atualização
  • Consideração de rebaixamento
  • Download
  • Problemas conhecidos
  • Relatar um problema

Observação

MongoDB 5.0 lançado em 13 de julho de 2021

Lançamentos de patches

Aviso

Limitações da versão anterior

Os avisos críticos abaixo afetam algumas versões anteriores do MongoDB. Se sua implantação depender de recursos afetados por um aviso crítico, atualize para a versão de patch mais recente disponível.

Emitir
Versões afetadas
WT-7984
5.0.0 - 5.0.2
5.0.0 - 5.0.2
5.0.0 - 5.0.14 (arquiteturas de sistema ARM64 ou POWER)
5.0.2 - 5.0.17 (Backups incrementais no Ops Manager ou clusters do Cloud Manager)
5.0.0 - 5.0.1
5.0.0 - 5.0.21
5.0.0 - 5.0.10
5.0.0 - 5.0.23
5.0.6 - 5.0.21 (Coleção de séries temporais fragmentadas por objetos embarcados metaField)
5.0.0 - 5.0.24

5.0.30 - 24 de outubro de 2024

Importante

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

No MongoDB 5.0 antes de 5.0.30, 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

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

  • Todos os problemas do JIRA foram encerrados em 5.0.30

  • 5.0.30 Registro de alterações

5.0.29 – 30 de setembro de 2024

Importante

A correção para a pesquisa automática de CSFLE e Queryable Encryption pode enviar valores em subpipelines como texto simples em vez de texto cifrado

Devido ao CVE-2024-8013, no MongoDB 5.0 antes de 5.0.28, um erro na análise de consultas de determinados subpipelines auto-representados complexos $lookup pode resultar em valores textuais em expressões para criptografados campos sendo enviados para o servidor malformados.

Caso isso ocorra, nenhum documento será devolvido ou escrito. Esse problema afeta o binário mongocryptd e a biblioteca compartilhada mongo_crypt_v1 nas seguintes versões do MongoDB Server:

  • 7.3.0 - 7.3.3

  • 7.0.0 - 7.0.11

  • 6.0.0 - 6.0.16

  • 5.0.0 - 5.0.28

Pontuação CVSS: 2.2

CWE: CWE-319: Transmissão de informações confidenciais em texto não criptografado

5.0.28 - 15 de julho de 2024

5.0.27 - 04 junho, 2024

5.0.26 - Mar 26, 2024

5.0.25 - 28 fevereiro de 2024

Importante

A correção para o MongoDB Server pode permitir uma conexão não confiável bem-sucedida

Devido ao CVE-2024-1351, no MongoDB 5.0 antes de 5.0.25, sob certas configurações de --tlsCAFile e CAFile, MongoDB Server pode ignorar a validação do certificado de par, o que pode resultar no sucesso de conexões não confiáveis.

Isso pode efetivamente reduzir as garantias de segurança fornecidas pelo TLS e conexões abertas que deveriam ter sido fechadas devido a falha na validação do certificado. Esse problema afeta as seguintes versões do MongoDB Server:

  • 7.0.0 - 7.0.5

  • 6.0.0 - 6.0.13

  • 5.0.0 - 5.0.24

  • 4.4.0 - 4.4.28

Pontuação CVSS: 8.8

CWE: CWE-295: validação de certificado inadequada

5.0.24 - Jan 18, 2024

5.0.23 - 27 de novembro de 2023

5.0.22 - 26 de outubro de 2023

5.0.21 - 12 de setembro de 2023

  • SERVER-60466 aceitar drivers para disseminação de $clusterTimes assinados para conjuntos de réplicas --shardsvr antes da execução do addShard

  • SERVER-71627 as informações de rota de coleção em cache atualizadas bloquearão severamente todas as solicitações do cliente quando um cluster tiver 1 milhões de blocos

  • SERVER-78813 a propagação do ponto de confirmação falha indefinidamente com cursores de exaustão com optime lastCommitted nulo.

  • WT-10759 não tente forçar novamente a remoção de páginas de armazenamento de histórico durante a reconciliação

  • WT-11051 corrigir a comparação mais recente de carimbos de data/hora duráveis de início na validação agregada de carimbos de data/hora

  • Todos os problemas do JIRA foram encerrados na versão 5.0.21

  • 5,0,21 Registro de alterações

5.0.20 - Ago 14 de 2023

5.0.19 - 13 de julho de 2023

5.0.18 - 18 de maio de 2023

Problemas corrigidos:

5.0.17 - abr 27 de 2023

Problemas corrigidos:

5.0.16 - abr 10 de 2023

Problemas corrigidos:

5.0.15 - 27 fevereiro de 2023

Problemas corrigidos:

5.0.14 - 21 de novembro de 2022

Problemas corrigidos:

5.0.13 - 29 de setembro de 2022

Problemas corrigidos:

  • SERVER-69611 configurar a opção do compilador -ffp-contract=off como padrão

  • SERVER-69220 o refineCollectionShardKey permite alternar os campos de chave de fragmento atuais entre baseados em intervalo e com hash, o que leva à incoerência dos dados

  • SERVER-67650 o destinatário de refragmentação pode retornar RemainingOperationTimeEstimatedSecs=0 quando o aplicador de oplog não alcançar o buscador de oplog

  • SERVER-68094 refragmentação com _id gerado de forma personalizada falha com erro de projeção

  • WT-9870 corrigir a atualização do carimbo de data/hora fixado sempre que o carimbo de data/hora mais antigo for atualizado durante a recuperação

  • Todos os problemas do JIRA foram encerrados em 5.0.13

  • 5.0.13 Registro de alterações

5.0.12 - 05 de setembro de 2022

Problemas corrigidos:

5.0.11 - Ago 19 de 2022

Problemas corrigidos:

5.0.10 - 29 de julho de 2022

Problemas corrigidos:

  • SERVER-66418 projeção incorreta criada durante a análise de dependência devido à suposição de ordem das strings

  • SERVER-65821 impasse durante setFCV quando há transações preparadas que não persistiram na decisão de confirmação/anulação

  • SERVER-65131 desativar a segmentação de leitura oportunista (exceto para leituras distribuídas)

  • SERVER-63971 alterar o parâmetro do servidor para o comportamento padrão de leitura das próprias gravações após a transação 2PC

  • SERVER-66433 prazo de backport aguardando a conclusão da exclusão do intervalo sobreposto para versões anteriores às versões v5.1

  • Todas as ocorrências do Jira fechadas em 5.0.10

  • 5.0.10 Registro de alterações

5.0.9 - 31 de maio de 2022

Problemas corrigidos:

5.0.8 - abr 25 de 2022

Problemas corrigidos:

  • SERVER-63531 o commitQuorum inclui incorretamente nós buildIndexes:false e a mensagem de erro diz incorretamente que apenas nós com direito de voto estão qualificados

  • SERVER-63387 1 o StreamingCursor deve retornar os blocos de backup na ordem em que foram recuperados do cursor de backup do WiredTiger

  • SERVER-62229 corrigir o invariante quando aplicar entradas de criação de índice quando recoverFromOplogAsStandalone=true

  • SERVER-61879 atualizações para recuperar migrações nunca devem entrar em atualizações contínuas

  • WT-8924 não verificar em relação à janela temporal do disco se houver uma lista de inserção quando verificar conflitos no armazenamento de linhas

  • Todos os problemas do JIRA foram encerrados na versão 5.0.8

  • 5,0,8 Registro de alterações

5.0.7 - abr 11 de 2022

Problemas corrigidos:

5.0.6 - 31 janeiro de 2022

Problemas corrigidos:

5.0.5 - 6 de dezembro de 2021

Problemas corrigidos:

5.0.4 - 15 de novembro de 2021

Problemas corrigidos:

5.0.3 - 21 de setembro de 2021

Problemas corrigidos:

5.0.2 - Ago 4 de 2021

Problemas corrigidos:

5.0.1 - 22 de julho de 2021

Problemas corrigidos:

5.0.0 - 13 de julho de 2021

O restante desta página fornece as notas de versão do 5.0.0:

Coleções de Time Series

O MongoDB 5.0 introduz coleções de séries temporais que armazenam eficientemente sequências de medições durante um período de tempo. Em comparação com coleções normais, armazenar dados de séries temporais em coleções de séries temporais melhora a eficiência da query e reduz o uso de disco para seus dados e índices.

Agregação

Novos operadores de aggregation

O MongoDB 5.0 introduz os seguintes operadores de agregação:

Operador
Descrição

$count (aggregation accumulator) fornece uma contagem de todos os documentos quando usado no estágio existente do pipeline $group (aggregation) e no novo estágio do MongoDB 5.0 $setWindowFields.

O $count (aggregation accumulator) é diferente do estágio de pipeline $count (aggregation) .

Aumenta um objeto Date() por um número específico de unidades de tempo.
Retorna a diferença entre duas datas.
Reduz um objeto Date() por um número específico de unidades de tempo.
Trunca uma data.
Retorna o valor de um campo especificado de um documento. Você pode usar $getField para recuperar o valor de campos com nomes que contenham pontos (.) ou comecem com cifrões ($).
O método $rand gera um valor flutuante aleatório entre 0 e 1 cada vez que é chamado. O novo operador $sampleRate é baseado em $rand.
Adiciona o método $sampleRate para selecionar documentos probabilisticamente de um pipeline em uma determinada taxa.
Adiciona, atualiza ou remove um campo especificado em um documento. Você pode usar $setField para adicionar, atualizar ou remover campos com nomes que contenham pontos (.) ou começar com cifrões ($).
Remove um campo especificado em um documento. Um alias para $setField remover campos com nomes que contêm pontos (.) ou que começam com sinais de dólar ($).

Operadores de Janela

O MongoDB 5.0 introduz o $setWindowFields estágio de pipeline , permitindo que você execute operações em uma extensão específica de documentos em uma coleção, conhecida como janela. A operação retorna os resultados baseado no operador de janela escolhido.

Por exemplo, você pode utilizar o estágio $setWindowFields para produzir o:

  • Diferença nas vendas entre dois documentos em uma coleção.

  • Classificações de vendas.

  • Total cumulativo de vendas.

  • Análise de informações complexas de séries temporais sem exportar os dados para um banco de dados externo.

Melhorias gerais de aggregation

$expr Operador: operadores de comparação usam índices

A partir de MongoDB 5.0, os operadores $eq, $lt, $lte, $gt e $gte colocados em um operador $expr podem utilizar índices para melhorar o desempenho.

$ifNull Expressão aceita múltiplas expressões de entrada

Iniciando no MongoDB 5.0, você pode especificar múltiplas expressões de entrada para a expressão $ifNull antes de retornar uma expressão de substituição.

let Opção para agregação

Iniciando no MongoDB 5.0, o comando aggregate e o método auxiliar do db.collection.aggregate() têm uma opção do let para especificar uma lista de variáveis que podem ser utilizadas em outro lugar no aggregation pipeline. Isso permite que você melhore a legibilidade do comando separando as variáveis do texto da query.

$lookup Estágio: subqueries correlacionadas concisas

A partir do MongoDB 5.0, um pipeline de agregação $lookup estágio oferece suporte a subquerys correlacionadas concisas que melhoram as junções entre coleções.

$lookup Estágio: subqueries não correlacionadas

A partir do MongoDB 5.0, para uma subquery não correlacionada em um estágio de pipeline $lookup contendo um estágio $sample, o operador $sampleRate ou o operador $rand, a subquery sempre é executada novamente se for repetida. Anteriormente, dependendo do tamanho da saída da subquery, a saída da subquery era armazenada em cache ou a subquery era executada novamente.

Consulte Executar uma Subquery Não Correlacionada com $lookup.

$sort Estágio: melhorias no desempenho

A partir do MongoDB 5.0, o otimizador de query empurra os resultados de um estágio de $project para o estágio $sort. Como resultado, as operações de $sort podem exigir menos RAM quando usadas com o estágio project e evitar erros Sort exceeded memory limit .

Auditoria

Configuração do filtro de auditoria de tempo de execução

O MongoDB 5.0 adiciona a capacidade de configurar filtros de auditoria no tempo de execução.

Operador
Descrição
Define o intervalo de pesquisa para verificar a configuração da auditoria
Recupera configurações de auditoria de mongod e mongos.
Define novas configurações de auditoria para instâncias do mongod e mongos no tempo de execução.

Atualizações gerais de auditoria

A partir do MongoDB 5.0:

Capped collections

Exclusões de coleções limitadas são replicadas para secundárias

A partir do MongoDB 5.0, as operações de exclusão implícitas para coleções limitadas do conjunto de réplicas são processadas pelo primário e replicadas para os membros secundários.

Exclusões explícitas permitidas em coleções limitadas

A partir do MongoDB 5.0.7, você pode excluir documentos de coleções limitadas usando métodos de exclusão.

Fluxos de alterações

Alterar saída de eventos

A partir do MongoDB 5.0, os eventos de alteração contêm o campo updateDescription.truncatedArrays para registrar truncamentos de array.

Indexes

Alteração de comportamento de índices parciais

A partir do MongoDB 5.0, vários índices parciais podem ser criados usando o mesmo padrão de chave, desde que os campos partialFilterExpression não expressem filtros equivalentes.

Nas versões anteriores do MongoDB, a criação de vários índices parciais não é permitida ao usar o mesmo padrão de chave com diferentes PartialFilterExpressions.

Mudança exclusiva de comportamento do índice esparso

A partir do MongoDB 5.0, índices esparsos e não esparsos exclusivos com o mesmo padrão de chave podem existir em uma única collection.

Consulte criação exclusiva de índice esparso

Não Ready é possível descartar índices durante construções de índices em andamento

O comando db.collection.dropIndexes() não pode descartar índices prontos se houver alguma construção de índice em andamento.

  • Nas versões 4.4.0-4.4.4 do MongoDB, esta lógica não era verdadeira devido a um bug.

A validação em primeiro plano pode corrigir inconsistências de metadados multichave

Quando executado em uma implantação do MongoDB, db.collection.validate() tenta corrigir inconsistências de metadados de várias chaves de implantações autônomas.

Remoção do geoHaystack índice e do geoSearch comando

O MongoDB 5.0 remove o índice geoHaystack obsoleto e o comando geoSearch. Em vez disso, use um 2d index com $geoNear ou um dos geospatial query operators compatíveis.

Atualizar sua instância MongoDB para 5.0 e configurar featureCompatibilityVersion para 5.0 excluirá quaisquer índices do geoHaystack preexistentes.

Novas mensagens de erro

As operações db.collection.createIndex() e db.collection.createIndexes() têm novas mensagens de erro quando as opções são especificadas incorretamente.

Construções de índice interrompidas

Se um nó em um conjunto de réplicas for desligado corretamente ou revertido durante uma compilação de índice, o progresso da compilação do índice será salvo no disco. Quando o servidor é reiniciado, a criação de índice é retomada a partir da posição salva.

reIndex Mudança de comportamento

A partir do MongoDB 5.0, o comando reIndex e o método db.collection.reIndex() shell só podem ser executados em instâncias autônomas.

Comandos removidos

A partir do MongoDB 5.0, estes comandos do banco de dados e métodos de assistente de shell mongo foram removidos:

Comando removido
Alternativa
Não disponível
Não disponível
Não disponível

Conjuntos de réplicas

Leituras não transacionais em config.transactions

A partir do MongoDB 5.0, as leituras sem transação não são permitidas na collection config.transactions com os seguintes read concerns e opções:

hello Comando

A partir do MongoDB 5.0, o comando hello e o método db.hello() foram introduzidos como substitutos do comando isMaster e do método db.isMaster(). A nova métrica de topologia connections.exhaustHello rastreia isso em connections.

Período quiesce

A partir do MongoDB 5.0, mongod e mongos entram em um período de inatividade para permitir que qualquer operação de banco de dados em andamento seja concluída antes do encerramento.

Limite removido para members[n]._id valores de

A partir de MongoDB 5.0, o campo members[n]._id pode ser qualquer valor inteiro maior ou igual a 0. Anteriormente, esse valor era limitado a um número inteiro entre 0 e 255 inclusive.

enableMajorityReadConcern Não é configurável

A partir do MongoDB 5.0, enableMajorityReadConcern e --enableMajorityReadConcern não podem ser alterados e são sempre definidos como true devido a melhorias no mecanismo de armazenamento.

Em versões anteriores do MongoDB, enableMajorityReadConcern e --enableMajorityReadConcern são configuráveis e podem ser configurados como false para evitar que a pressão do cache de armazenamento imobilize um sistema com uma arquitetura PSA (primary-secondary-arbiter) de três membros.

Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:

Controle aprimorado de timeout do pool de threads

A partir do MongoDB 5.0, você pode usar o novo parâmetro de servidor replWriterMinThreadCount para permitir que threads ociosos acima desse mínimo sejam fechados. Quando replWriterMinThreadCount é configurado com um valor menor que replWriterThreadCount, as threads ociosas acima de replWriterMinThreadCount atingem o tempo limite.

Reconfigurando conjuntos de réplicas PSA

Ao reconfigurar conjuntos de réplicas de primarias-secundárias-arbiter (PSA) ou mudar para uma arquitetura PSA, agora é necessário, em alguns casos, realizar a reconfiguração em uma mudança de duas etapas. O MongoDB 5.0 apresenta o método rs.reconfigForPSASet() que executa ambas as etapas. Se você não puder usar o método auxiliar, siga o procedimento em Modificar um conjunto de réplicas de PSA autogerenciadocom segurança.

Limitar reavaliações da fonte de sincronização

maxNumSyncSourceChangesPerHour determina quantas alterações de fonte de sincronização podem ocorrer por hora antes que o nó pare temporariamente de reavaliar uma fonte de sincronização. Esse parâmetro não impedirá que um nó comece a sincronizar a partir de outro nó se ele não tiver uma fonte de sincronização.

enableOverrideClusterChainingSetting Server Parameter

A partir do MongoDB 5.0.2, você pode definir o novo parâmetro do servidor enableOverrideClusterChainingSetting como true para permitir que os membros secundários repliquem dados de outros membros secundários, mesmo que settings.chainingAllowed seja false.

Segurança

Compatível com rotação de certificados online

A partir do MongoDB 5.0, agora você pode girar os seguintes certificados TLS sob demanda sem primeiro precisar interromper a execuçãomongod ou mongos instância:

Para girar esses certificados, substitua os arquivos de certificado no sistema de arquivos por versões atualizadas e use o comando rotateCertificates ou o método db.rotateCertificates() shell para disparar a rotação do certificado.

A rotação de certificados dessa maneira não requer tempo de inatividade e não descarta nenhuma conexão remota ativa.

Consulte Rotação de certificados on-line para obter detalhes completos.

Suporte para configuração de conjuntos de criptografia TLS 1.3

O MongoDB 5.0 introduz o parâmetro opensslCipherSuiteConfig para habilitar a configuração dos conjuntos de criptografia suportados OpenSSL deve permitir ao utilizar criptografia TLS 1.3.

Aviso de inicialização do certificado de conexão TLS X509

A partir do MongoDB 5.0, mongod e mongos agora emitem um aviso de inicialização quando seus certificados não incluem um atributo Subject Alternative Name.

As seguintes plataformas não suportam validação de nome comum:

  • iOS 13 e superior

  • MacOS 10.15 e superior

  • Vá para 1,15 e superior

Os clientes que usam essas plataformas não se autenticarão em servidores MongoDB que usam certificados x.509 cujos nomes de host são especificados por atributos CommonName.

Ação de privilégio do ApplyOps

O MongoDB 5.0 introduz a ação de privilégio do applyOps que é herdada pelo dbAdminAnyDatabase.

A ação applyOps permite que os usuários executem o comando de banco de dados applyOps.

Clusters fragmentados

Refragmentação

A chave de shard ideal permite que o MongoDB distribua documentos uniformemente em todo o cluster, ao mesmo tempo em que facilita padrões de query comuns. Uma chave de shard abaixo do ideal pode levar a problemas de desempenho ou dimensionamento devido à distribuição desigual de dados. A partir do MongoDB 5.0, você pode usar o comando reshardCollection para alterar a chave de shard de uma collection para alterar a distribuição dos dados no cluster.

currentOp Relata operações de refragmentação em andamento

A partir do MongoDB 5.0, o estágio de agregação $currentOp (e o comando currentOp e o método de shell db.currentOp()) inclui informações adicionais sobre o status das operações de refragmentação em andamento para o coordenador de refragmentação e os fragmentos doador e receptor.

db.currentOp Método agora usa estágio de aggregation em mongosh

A partir do MongoDB 5.0, o estágio de agregação $currentOp é usado ao executar o método auxiliar db.currentOp() com mongosh.

mongos / mongod Conjunto de conexões

A partir do MongoDB 5.0, o MongoDB adiciona a opção de parâmetro "automatic" como o novo padrão para o ShardingTaskExecutorPoolReplicaSetMatching. Quando configurado para um mongos, a instância segue o comportamento especificado para a opção "matchPrimaryNode". Quando configurado para um mongod, a instância segue o comportamento especificado para a opção "disabled".

renameCollection Compatível com coleções compartilhadas

A partir do MongoDB 5.0, você pode utilizar o comando renameCollection para alterar o nome de uma collection fragmentada.

Ao renomear uma collection fragmentada ou não fragmentada em um cluster fragmentado, as collections de origem e de destino são bloqueadas exclusivamente em cada shard. As operações subsequentes nas collections de origem e de destino devem aguardar até que a operação de renomeação seja concluída.

movePrimary Mensagem de erro para gravações durante a operação

A partir do MongoDB 5.0, ao usar o comando movePrimary para remover um fragmento de um cluster fragmentado, as gravações no fragmento original gerarão uma mensagem de erro.

Dividir e mesclar logs de alterações de chunks mostra o shard proprietário

A partir do MongoDB 5.0, os documentos na coleção config.changelog para operações de divisão e mesclagem contêm um campo owningShard. O campo owningShard mostra o shardId do fragmento que possui as partes que foram divididos ou mescladas.

O campo owningShard ajuda a identificar fragmentos onde ocorrem operações de divisão ou mesclagem com frequência.

maxCatchUpPercentageBeforeBlockingWrites Server Parameter

A partir do MongoDB 5.0, você pode definir o maxCatchUpPercentageBeforeBlockingWrites para especificar a porcentagem máxima permitida de dados ainda não migrados durante uma operação moveChunk em comparação com o tamanho total (em MBs) do bloco que está sendo transferido.

Esse parâmetro pode afetar o comportamento de:

Mudanças no shell

Novo shell MongoDB: mongosh

O shell mongo foi descontinuado no MongoDB v5.0. O shell de substituição é mongosh. O shell herdado mongo será removido em uma versão futura.

O empacotamento do shell também muda no MongoDB v5.0. Consulte as instruções de instalação para ver mais detalhes.

Suporte da Shell para provedores do GCP e do Azure KMS

A partir do MongoDB 5.0, o KMS do Google Cloud Platform e o Azure Key Vault são compatíveis tanto com o shell mongosh quanto com o shell legado mongo como provedores de serviço de gerenciamento de chaves (KMS) para criptografia de nível de campo no lado do cliente.

Usando um KMS, você pode armazenar de forma centralizada e segura as chaves mestras do cliente (CMKs), que são usadas para criptografar e descriptografar chaves de criptografia de dados como parte do fluxo de trabalho de criptografia em nível de campo no lado do cliente.

Além disso, um KMS configurado permite o uso de Como o CSFLE descriptografa documentos de campos de dados quando usado com MongoDB Enterprise.

Para saber mais, consulte Configurar um provedor de KMS usando o mongosh.

Snapshots

Compatibilidade estendida para read concern "snapshot"

A partir do MongoDB 5.0, os read concerns "snapshot" são compatíveis com algumas operações de leitura fora de transações multidocumento em primaries e secundários. Consulte Executar queries de snapshots de longa execução.

minSnapshotHistoryWindowInSeconds Server Parameter

Iniciando no MongoDB 5.0, você pode utilizar o parâmetro minSnapshotHistoryWindowInSeconds para controlar por quanto tempo o WiredTiger mantém o histórico de snapshots.

Transações

coordinateCommitReturnImmediatelyAfterPersistingDecision Parâmetro

O parâmetro do servidor coordinateCommitReturnImmediatelyAfterPersistingDecision controla quando as decisões feitas na transação são devolvidas ao cliente.

O parâmetro foi introduzido no MongDB 5.0 com um valor padrão de true. No MongoDB 6.1, o valor padrão muda para false.

Quando coordinateCommitReturnImmediatelyAfterPersistingDecision é false, o coordenador de transação de fragmento aguarda que todos os membros reconheçam uma confirmação de transação de vários documentos antes de retornar a decisão de confirmação ao cliente.

Alterações de nomenclatura

A partir de fevereiro de 2022, a terminologia "API versionada" foi alterada para "API estável". Todos os conceitos e funcionalidades permanecem os mesmos com essa mudança de nomenclatura.

Alterações gerais

Estatística do plano de execução da query com $lookup estágio de pipeline

O MongoDB 5.0 adiciona estatísticas de plano de execução para queries que usam um estágio de pipeline $lookup.

Manipulação aprimorada de$() e.() em nomes de campo

O MongoDB 5.0 adiciona suporte melhorado para nomes de campo que são ($) prefixados ou que contêm (.) caracteres. As regras de validação para armazenar dados foram atualizadas para facilitar o trabalho com fontes de dados que usam esses caracteres.

Preocupação com gravação padrão em todo o cluster

A partir do MongoDB 5.0, uma vez que a preocupação com a gravação em todo o cluster (CWWC) é definida por meio do comando setDefaultRWConcern, a preocupação com a gravação não pode ser desfeita.

Write concern padrão implícito

A partir do MongoDB 5.0, o write concern padrão implícito é w: majority. No entanto, considerações especiais são feitas para sistemas contendo arbiters:

  • A maioria dos votos de um conjunto de réplicas é de 1 mais metade do número de membros votantes, arredondado para baixo. Se o número de membros votantes portadores de dados não for maior que a maioria votante, o write concern padrão é { w: 1 }.

  • Em todos os outros cenários, a preocupação de gravação padrão é { w: "majority" }.

Especificamente, MongoDB usa a seguinte fórmula para determinar a preocupação de escrita padrão:

if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ]
    defaultWriteConcern = { w: 1 }
else
    defaultWriteConcern = { w: "majority" }

Por exemplo, considere as seguintes implantações e suas respectivas preocupações de escrita padrão:

Non-Arbiters
Árbitros
Nós de votação
Maioria dos nós de votação
Write concern padrão implícito
2
1
3
2
{ w: 1 }
4
1
5
3
{ w: "majority" }

  • No primeiro exemplo:

    • Existem 2 não-arbitores e 1 árbitro para um total de 3 nós de votação.

    • A maioria dos nós de votação (1 mais metade de 3, arredondado para baixo) é 2.

    • O número de não-arbitros (2) é igual à maioria dos nós de votação (2), resultando em uma preocupação implícita de escrita de { w: 1 }.

  • No segundo exemplo:

    • Existem 4 não-árbitros e 1 árbitro para um total de 5 nós votantes.

    • A maioria dos nós de votação (1 mais metade de 5, arredondado para baixo) é 3.

    • O número de não-arbitros (4) é maior que a maioria dos nós de votação (3), resultando em uma preocupação implícita de escrita de { w: "majority" }.

O write concern padrão { w: "majority" } oferece uma garantia de durabilidade mais forte no caso de uma eleição ou se os membros do conjunto de réplicas ficarem indisponíveis.

mongosShutdownTimeoutMillisForSignaledShutdown Parâmetro

A partir do MongoDB 5.0, o novo parâmetro mongosShutdownTimeoutMillisForSignaledShutdown especifica o tempo, em milissegundos, para aguardar a conclusão de qualquer operação de banco de dados em andamento antes de iniciar um desligamento demongos.

Nível de compactação configurável<a zstd class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \" class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\" \"> <path fill=\" \" d=\" \">

O MongoDB 5.0 apresenta a opção de arquivo de configuração do zstdCompressionLevel que permite níveis de compressão configuráveis quando o blockCompressor está definido para zstd.

Operações de leitura sem travamento

A partir do MongoDB 5.0, as seguintes operações de leitura não são bloqueadas quando outra operação mantém um bloqueio de escrita exclusivo (X) na collection:

Ao escrever em uma collection, mapReduce e aggregate mantêm uma trava exclusiva de intenção (IX). Portanto, se uma trava X exclusiva já estiver mantida em uma collection, as operações de escrita mapReduce e aggregate serão bloqueadas.

Falhas na validação do esquema explicadas

O MongoDB 5.0 adiciona explicações detalhadas quando um documento falha na validação de esquema.

Opção de reparo no validate comando

A partir do MongoDB 5.0, o comando validate e o método auxiliar db.collection.validate() têm uma nova opção de reparo para reparar uma coleção com inconsistências.

O comando validate e o método auxiliar db.collection.validate() também retornam um novo valor booleano repaired que é true se a coleção foi reparada.

validate Comando relata violações de esquema de documento

A partir do MongoDB 5.0, validate e db.collection.validate() validam documentos em uma collection. Os comandos relatam se alguma regra de validação de esquema foi violada.

Opção de reparo em mongod

A partir do MongoDB 5.0, a opção --repair para mongod valida as collections para encontrar quaisquer inconsistências e as corrige, se possível, o que evita a reconstrução dos índices. Consulte a opção --repair para uso e limitações.

corruptRecords Campo na saída de validação

A partir do MongoDB 5.0, o comando validate e o método auxiliar db.collection.validate() retornam um novo campo corruptRecords que contém uma array de valores RecordId para documentos corrompidos.

maxValidateMemoryUsageMB Server Parameter

A partir do MongoDB 5.0, o comando setParameter tem um novo parâmetro maxValidateMemoryUsageMB, que define o uso máximo de memória para o comando validate.

findChunksOnConfigTimeoutMS Server Parameter

A partir do MongoDB 5.0, você pode usar o parâmetro findChunksOnConfigTimeoutMS para alterar o tempo limite para operações de localização em chunks.

Opção filter do Profiler de banco de dados

A partir do MongoDB 5.0, você pode definir uma opção filter para o criador de perfil de banco de dados para determinar quais operações são perfiladas e registradas. Você pode usar a expressão filter no lugar das opções de perfil slowms e sampleRate.

Consulte:

Registrar alterações nas configurações do Database Profiler

A partir do MongoDB 5.0, as alterações feitas no profiler de banco de dados level, slowms, sampleRate ou filter usando o comando profile ou o método wrapper db.setProfilingLevel() são registradas no log file.

Rotação de registro independente para registros de servidor e auditoria

A partir do MongoDB 5.0, quando a auditoria está ativada, agora você pode girar o servidor e os logs de auditoria independentemente usando o comando logRotate. Anteriormente, logRotate rotacionava os dois logs juntos.

remote Campo em logs de operação lentos

A partir do MongoDB 5.0, as mensagens de registro de operações lentas incluem um campo remote que especifica o endereço IP do cliente.

remoteOpWaitMillis Campo de registro

A partir do MongoDB 5.0, você pode usar o campo de registro remoteOpWaitMillis para obter o tempo de espera dos resultados dos fragmentos.

resolvedViews Campo de log para queries lentas sobre visualizações

A partir do MongoDB 5.0, as mensagens de registro para queries lentas em exibições incluem um campo resolvedViews que contém os detalhes da exibição.

Defina variáveis usando a let opção

Iniciando no MongoDB 5.0, os seguintes comandos têm uma opção let para definir uma lista de variáveis. Isso permite que você melhore a legibilidade do comando separando as variáveis do texto da consulta.

O comando update também tem um campo c para definir uma lista de variáveis.

Suporte para mapeamento de nome de usuário para DN LDAP por padrão

A partir do MongoDB 5.0, a opção de arquivo de configuração userToDNMapping e a opção de linha de comando --ldapUserToDNMapping para mongod / mongos e mongoldap agora mapeiam o nome de usuário autenticado como o DN LDAP por padrão se for um documento de mapeamento vazio (ou seja, uma string vazia ou uma matriz vazia) é especificado para a opção. Anteriormente, fornecer um documento de mapeamento vazio causaria falha no mapeamento.

dbStats Estatísticas adicionais de espaço livre <a class=\" \" href=\" \" title=\" \"><svg xmlns=\" \" width=\" \" height=\" \" fill=\" \" viewbox=\" \" class=\" \" role=\" \" aria-label=\" \"><path fill=\" \" d=\" \"> <path fill=\" \" d=\" \">

Iniciando no MongoDB 5.0, o comando dbStats gera estas estatísticas adicionais:

serverStatus Alteração de saída

serverStatus inclui os seguintes novos campos em sua saída:

Métricas de agregação
Métricas de versão da API
Métricas de replicação
Ler contadores de preocupações
Contadores de write concern

  • opWriteConcernCounters agora tem os seguintes novos campos:

    • opWriteConcernCounters.insert.noneInfo

    • opWriteConcernCounters.update.noneInfo

    • opWriteConcernCounters.delete.noneInfo

Número de conexões roscadas

  • connections.threaded, que relata o número de conexões recebidas de clientes que são atribuídas a threads que o cliente de serviço solicita

Estatísticas de refragmentação
Métricas do executor do serviço

  • network.serviceExecutors, que informa sobre os executores de serviço que executam operações para solicitações de clientes

Métricas do cursor
Contador de segurança
Rep.

  • O repl agora inclui um documento do primaryOnlyServices que contém informações adicionais sobre serviços que são executados somente em primaries de conjunto de réplicas.

Limite de tamanho das informações de depuração do cache do plano

A partir do MongoDB 5.0, o cache do plano salvará entradas completas de plan cache somente se o tamanho cumulativo de plan caches para todas as coleções for inferior a 0,5 GB. Quando o tamanho cumulativo de plan caches para todas as coleções exceder esse limite, as entradas de plan cache adicionais serão armazenadas sem determinadas informações de depuração.

O tamanho estimado em bytes de uma entrada plan cache está disponível na saída de $planCacheStats.

Fechamento de cursores inativos aberto dentro de uma sessão

A partir do MongoDB 5.0, os cursores criados em uma sessão do cliente são fechados quando a sessão do servidor correspondente termina com o comando killSessions , se a sessão atingir o tempo limite ou se o cliente tiver esgotado o cursor. Consulte Iterar um cursor no mongosh.

Novo validateDBMetadata comando

O MongoDB 5.0 adiciona o comando validateDBMetadata. O comando validateDBMetadata verifica se os metadados armazenados de um banco de dados ou de uma collection são válidos em uma determinada versão da API.

Considerações de desempenho

Write concern padrão implícito

O MongoDB 5.0 altera a preocupação de gravação padrão para { w: "majority" }. A nova preocupação de gravação padrão pode afetar o desempenho, pois o MongoDB reconhece as gravações somente depois que uma maioria calculada de membros do conjunto de réplicas tiver executado e persistido a gravação no disco.

Se o seu aplicativo depender de gravações sensíveis ao desempenho, você poderá substituir a preocupação de gravação padrão ao custo de garantias de durabilidade dos dados. Para substituir essa configuração, você pode:

  • Defina a preocupação de gravação no nível de operação individual para gravações críticas de desempenho. Para obter mais informações, consulte a documentação do driver.

  • Use o comando setDefaultRWConcern para definir explicitamente a preocupação de gravação padrão.

Aviso

Se as operações de gravação usarem a preocupação de gravação { w: 1 }, o diretório de rollback poderá excluir as gravações enviadas após um oplog hole se o primário for reiniciado antes que a operação de gravação seja concluída.

local Preocupação de leitura padrão

A partir do MongoDB 5.0, "local" é o read concern padrão para operações de leitura contra o primary e o secundário.

Isso pode introduzir um aumento significativo de latência para queries de contagem que usam um filtro e para queries cobertas.

Você pode desativar esse comportamento definindo a preocupação de leitura em todo o cluster com setDefaultRWConcern.

Retenção do Histórico de Snapshot

O MongoDB 5.0 aumenta o valor padrão de minSnapshotHistoryWindowInSeconds para 300, o que pode impactar negativamente o desempenho. Se você não estiver usando a preocupação de leitura "snapshot", poderá reduzir o valor do parâmetro minSnapshotHistoryWindowInSeconds para 5 em todas as mongod instâncias. Para obter mais informações, consulte Retenção do histórico de snapshots.

Observação

Se você estiver executando um cluster fragmentado, não altere minSnapshotHistoryWindowInSeconds nos servidores de configuração.

Suporte a plataformas

Microarquitetura mínima

O MongoDB 5.0 introduz os seguintes requisitos mínimos de microarquitetura:

CPU
Microarquitetura mínima suportada
Intel x86_64

MongoDB 5.0 requer um dos seguintes:

  • Processador Intel Sandy Bridge ou Core posterior, ou

  • Processador Intel Tiger Lake ou posterior Celeron ou Pentium.

AMD x86_64
O MongoDB 5.0 exige AMD Bulldozer ou posterior.
BRAÇO arm64
O MongoDB 5.0 exige ARMv8,2-A ou posterior.

O MongoDB v5.0 não é compatível com plataformas x86_64 ou arm64 que não atendam a esses requisitos mínimos de microarquitetura.

Consulte Suporte à plataforma x86_64 para obter mais informações.

Plataformas removidas

O MongoDB 5.0 remove a compatibilidade com as seguintes plataformas:

Consulte Suporte à plataforma para obter a lista completa de plataformas e arquiteturas suportadas no MongoDB 5.0.

Alterações que afetam a compatibilidade

Algumas alterações podem afetar a compatibilidade e podem exigir ações do usuário. Para obter uma lista detalhada de alterações de compatibilidade, consulte Alterações de compatibilidade no MongoDB 5.0.

Procedimentos de atualização

Importante

Versão de compatibilidade de recursos

Para atualizar para o MongoDB 5.0 a partir de um sistema 4.4, o sistema 4.4 deve ter featureCompatibilityVersion configurado como 4.4. Para verificar a versão:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

Para atualizar para o MongoDB 5.0, consulte as instruções de atualização específicas para a implantação do MongoDB.

Se precisar de orientação sobre como atualizar para a versão 5.0, os serviços profissionais do MongoDB viabilizam o upgrade da versão principal para ajudar a garantir uma transição sem percalços, sem interrupção para o seu aplicativo do MongoDB.

Consideração de rebaixamento

O MongoDB suporta apenas downgrades de versão única. Você não pode fazer o downgrade para uma versão que esteja várias versões atrás da versão atual.

Por exemplo, você pode desatualizar uma série 5.0 para uma série 4.4. No entanto, não há suporte para desatualização adicional dessa implantação série 4.4 para uma implantação série 4.2.

Download

Para baixar o MongoDB 5.0, acesse a Central de download do MongoDB.

Dica

Veja também:

Problemas conhecidos

Na versão
Problemas
Status
5.0.0
SERVIDOR-58171: o parâmetro de uma coleção Time Series granularity não pode ser modificado após a criação da coleção.
Corrigido em 5.0.1
5.0.0
SERVER-58392: uma operação de refragmentação contínua pode impedir que a realização de operações de backup ou restauração.
Corrigido em 5.0.3

Relatar um problema

Para relatar um problema, consulte o repositório MongoDB no GitHub para obter instruções sobre como arquivar um ticket do JIRA para o servidor MongoDB ou um dos projetos relacionados.

Voltar

Registro de alterações

Próximo

Alterações de compatibilidade