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

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

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

Importante

A correção para CSFLE e a autoconsulta do Queryable Encryption podem enviar valores em subpipelines como texto simples em vez de texto cifrado

Devido ao CVE-2024-8013, no MongoDB 5.0 anterior a 5.0.28, um bug na análise de query de determinados subpipelines auto-referenciais $lookup complexos pode resultar em valores literais em expressões para campos criptografados sendo enviados para o servidor malformado.

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 texto não criptografado de informações confidenciais

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

  • 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

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

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

Problemas corrigidos:

Problemas corrigidos:

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

Problemas corrigidos:

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

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

Problemas corrigidos:

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

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.

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 ($).

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.

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.

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.

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.

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.

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.

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 .

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.

A partir do MongoDB 5.0:

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.

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

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

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.

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

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.

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.

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.

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

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.

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.

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

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:

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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".

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.

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.

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.

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:

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Dica

Veja também:

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

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