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

Notas de versão para MongoDB 4.4

Nesta página

  • Lançamentos de patches
  • Requisitos de captura de dados de diagnóstico em tempo integral
  • Agregação
  • Conjuntos de réplicas
  • Clusters fragmentados
  • Projeção
  • Transações
  • Classificação
  • Melhorias na segurança
  • Registro estruturado
  • Suporte a plataformas
  • mongo shell
  • Ferramentas
  • Drivers
  • Índices
  • Comandos removidos
  • Networking
  • Melhorias gerais
  • Alterações que afetam a compatibilidade
  • Procedimentos de atualização
  • Consideração de rebaixamento
  • Download
  • Problemas conhecidos
  • Relatar um problema

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-7426
4.4.5
4.4.8
4.4.2 - 4.4.8
4.4.0 - 4.4.18 (arquiteturas de sistema ARM64 ou POWER)
4.4.8 - 4.4.21 (Backups incrementais no Ops Manager ou clusters do Cloud Manager)
4.4.7

Lançamentos de patches

4.4.29 - 28 de fevereiro de 2024

Importante

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

Devido a CVE-2024-1351, no MongoDB 4.4 antes de 4.4.29, sob certas configurações de --tlsCAFile e CAFile, o Servidor MongoDB 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

4.4.28 - 18 janeiro de 2024

4.4.27 - 3 janeiro de 2024

4.4.26 - 27 de novembro de 2023

Problemas corrigidos:

4.4.25 – 29 de setembro de 2023

Problemas corrigidos:

  • SERVER-76299 Reportar writeConflicts em serverStatus em secundários

  • SERVER-78828 Os dados de tempo do host LDAP podem ser inconsistentes durante a classificação

  • WT-11031 corrigir RTS para ignorar tabelas sem informações de janela de tempo no checkpoint

  • SERVER-70973 O balanceador deve parar de iterar as coleções quando não houver mais fragmentos disponíveis

  • 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-8570 Não aumenta o ID mais antigo durante a recuperação

  • WT-10449 não salvar a cadeia de atualizações quando não houver atualizações a serem gravadas no armazenamento de histórico

  • Todos os problemas do JIRA foram encerrados em 4.4.25

  • 4.4.25 Registro de alterações

4.4.24 - Ago 23 de 2023

Problemas corrigidos:

4.4.23 - 13 de julho de 2023

4.4.22 - 18 maio de 2023

4.4.21 - 27 de abril de 2023

Problemas corrigidos:

4.4.20 - abr 10 de 2023

Problemas corrigidos:

4.4.19 - 27 fevereiro de 2023

Problemas corrigidos:

4.4.18 - 21 de novembro de 2022

Problemas corrigidos:

4.4.17 – 28 de setembro de 2022

Problemas corrigidos:

4.4.16 - Ago 19 de 2022

Problemas corrigidos:

4.4.15 - 21 junho, 2022

Problemas corrigidos:

4.4.14 - 9 maio de 2022

Problemas corrigidos:

4.4.13 - Mar 7, 2022

Problemas corrigidos:

4.4.12 - 21 janeiro de 2022

Problemas corrigidos:

4.4.11 - 30 de dezembro de 2021

Problemas corrigidos:

4.4.10 - 15 de outubro de 2021

Problemas corrigidos:

4.4.9 – 21 de setembro de 2021

Problemas corrigidos:

4.4.8 - Ago 4 de 2021

Problemas corrigidos:

  • SERVER-58936: as restrições de índice único podem não ser forçadas

  • SERVER-58258: aguarda a sincronização inicial para limpar o estado antes de afirmar que a resposta "replSetGetStatus" não tem o campo "initialSync"

  • SERVIDOR-52906: após uma migração com falha que reverteu os índices de clonagem, o moveChunk pode ficar suspenso indefinidamente devido à falta de um índice de chave de fragmento

  • WT-7837: Limpa a estrutura de atualizações em wt_hs_insert_updates para não ativar assert

  • WT-6729: pausar a remoção antes de executar a verificação de transações ativas do rollback para um estado estável

  • Todos os problemas do JIRA foram encerrados em 4.4.8

  • 4.4.8 Registro de alterações

4.4.7 - 16 de julho de 2021

Problemas corrigidos:

4.4.6 - 10 maio de 2021

Problemas corrigidos:

4.4.5 - abr 8 de 2021

Problemas corrigidos:

4.4.4 - 16 fevereiro de 2021

Problemas corrigidos:

  • SERVER-48471: os índices com hash podem ser marcados incorretamente como multichave e não podem ser qualificados como chave de fragmento

  • SERVIDOR-50769: servidor reiniciado após expr{"expr":"_currentApplyOps.getArrayLength() > 0","file":"src/mongo/db/pipeline/document_source_change_stream_transform.cpp","line":535}}

  • SERVER-52919: compressão de fio não habilitada para sincronização inicial

  • WT-7109: Mantém opções de configuração não suportadas para possibilitar compatibilidade com versões anteriores

  • WT-7117: RTS para ignorar as modificações que são mais recentes do que a atualização de base no disco ao restaurar uma atualização

  • Todos os problemas do JIRA foram encerrados em 4.4.4

  • 4.4.4 Registro de alterações

4.4.3 - 4 de janeiro de 2021

Problemas corrigidos:

4.4.2 - 18 de novembro de 2020

Problemas corrigidos:

4.4.1 – 9 de setembro de 2020

Problemas corrigidos:

  • SERVER-48531: Um impasse de 3 vias pode ocorrer entre o divisor de partes, as transações preparadas e o thread de redução.

  • SERVER-48641: Deadlock devido ao MigrationDestinationManager estar aguardando preocupação de gravação com a sessão em check-out

  • SERVER-49546: setFCV para 4.4 deve inserir tarefas de exclusão de faixa em lotes em vez de uma de cada vez

  • SERVIDOR-49694: Em um cluster fragmentado, leituras distribuídas ou mais próximas não podem ser encaminhadas para uma réplica próxima ao fragmento.

  • SERVER-50137: o MongoDB falha com falha invariante devido a entradas de oplog geradas em 3.4

  • SERVER-50140: a sincronização inicial não pode sobreviver à reinicialização impura da fonte da sincronização

  • SERVIDOR-50170: Corrigir falha de seleção de servidor no mongos

  • WT-6623: Definir o ID do arquivo de nível de conexão na verificação do arquivo de recuperação

  • Todos os problemas do JIRA foram encerrados em 4.4.1

  • 4.4.1 Registro de alterações

Requisitos de captura de dados de diagnóstico em tempo integral

A partir da versão 4.4, se o thread de captura de dados de diagnóstico em tempo integral (FTDC) em mongod ou mongos falhar, ele encerrará o processo de origem. Para evitar as falhas mais comuns, confirme se o usuário que executa o mongod/mongos tem permissões para criar o diretório diagnostic.data FTDC dentro storage.dbPath (para mongod) ou paralelo a systemLog.path (para mongos).

Agregação

União de todos (estágio$unionWith )

MongoDB 4.4 adiciona o estágio de agregação $unionWith, fornecendo a capacidade de combinar os resultados do pipeline de várias coleções em um único conjunto de resultados.

Para detalhes, consulte $unionWith.

Expressões de agregação personalizadas

A partir da versão 4.4, O MongoDB fornece os seguintes novos operadores que permitem aos usuários definir expressões de agregação personalizadas:

Com a adição desses novos operadores, você pode usar a agregação para escrever expressões JavaScript personalizadas em vez de confiar em mapReduce e $where.

Observação

Mesmo antes da versão 4.4, várias expressões de map-reduce também podiam ser reescritas usando outros estágios do pipeline de agregação, como $group, $merge etc., sem a necessidade de funções personalizadas.

Para obter mais informações, consulte Map-Reduce no pipeline de agregação.

Novos operadores de aggregation

Operador
Descrição
Retorna o resultado de um operador acumulador definido pelo usuário.
Retorna o tamanho de uma determinada string ou o conteúdo do valor dos dados binários em bytes.
Retorna o tamanho em bytes de determinado documento (ou seja, bsontype Object) quando codificado como BSON.
Define uma expressão de agregação personalizada.

Retorna booleano true se a expressão especificada produzir um integer, decimal, double ou long.

Retorna o booleano false se a expressão produzir qualquer outro tipo BSON, null ou um campo ausente.

Substitui a primeira instância de uma string correspondente em uma determinada entrada.
Substitui todas as instâncias de uma string correspondente em uma determinada entrada.

Melhorias gerais de aggregation

$out

Começando no MongoDB 4.4:

  • $out pode gerar uma saída para uma coleção em um banco de dados diferente. Nas versões anteriores, $out só podia gerar uma saída para uma coleção no mesmo banco de dados em que a agregação fosse executada.

  • $out só pode ser executado em nós secundários do conjunto de réplicas se todos os nós no cluster tiverem featureCompatibilityVersion definido como 4.4 ou superior e a Preferência de Leitura permitir leituras secundárias. Verifique a documentação do driver para ver quando seu driver adicionou suporte.

$indexStats

A partir do MongoDB 4.4 (também disponível a partir de 4.2.4), $indexStats inclui os seguintes campos em sua saída:

Campo
Descrição
Nome do fragmento, se aplicável.
Documento de especificação de índice
Um sinalizador booleano que indica se o índice está sendo criado no momento.

$merge

Começando no MongoDB 4.4:

  • $merge pode gerar uma saída para uma coleção em um banco de dados diferente. Nas versões anteriores, $merge só podia gerar uma saída para uma coleção do mesmo banco de dados em que a agregação fosse executada.

  • $merge só pode ser executado em nós secundários do conjunto de réplicas se todos os nós no cluster tiverem featureCompatibilityVersion definido como 4.4 ou superior e a Preferência de Leitura permitir leituras secundárias. Verifique a documentação do driver para ver quando seu driver adicionou suporte.

$merge pode gerar saída para a mesma coleção que está sendo agregada. Você também pode gerar saída para uma coleção que aparece em outros estágios do pipeline, como $lookup.

Aviso

Quando $merge gera saídas para a mesma coleção que está sendo agregada, os documentos podem ser atualizados várias vezes ou a operação pode resultar em um loop infinito. Esse comportamento ocorre quando a atualização realizada por $merge altera o local físico dos documentos armazenados no disco. Quando a localização física de um documento muda, $merge pode considerá-lo um documento totalmente novo, resultando em atualizações adicionais. Para obter mais informações sobre esse comportamento, consulte Problema de Halloween.

$planCacheStats Mudanças

A partir da versão 4.4,

$collStats Mudanças

A partir do MongoDB 4.4, $collStats aceita o campo queryExecStats como documento de argumento. Fornecer esse campo retorna os seguintes campos na saída:

O campo collectionScans contém um documento incorporado com os seguintes campos:

Nome do campo
Descrição
total
Um inteiro de 64 bits que informa o número total de query que executaram uma varredura de collection. O total consiste em query que usaram e não usaram um cursor persistente.
nonTailable
Um inteiro de 64 bits que informa o número de queries que executaram uma varredura de collection que não usou um cursor tailable.

explain Mudanças

A partir do MongoDB 4.4, quando você executa o db.collection.explain().aggregate() método nos modos executionStats e allPlansExecution, cada estágio do pipeline listado na saída de explicação inclui nReturned e executionTimeMillisEstimate.

Conjuntos de réplicas

Sincronização inicial retomável

A partir do MongoDB 4.4, uma sincronização inicial secundária pode tentar retomar o processo de sincronização se for interrompida por um transitório (ou seja, temporário) erro de rede, descarte de coleção ou renomeação de coleção. A fonte de sincronização também deve executar o MongoDB 4.4 para suportar a sincronização inicial retomável. Se a origem de sincronização executar o MongoDB 4.2 ou anterior, o secundário deverá reiniciar o processo de sincronização inicial como se encontrasse um erro de rede não transitório.

Por padrão, a secundária tenta retomar a sincronização inicial por 24 horas. O MongoDB 4.4 adiciona o parâmetro initialSyncTransientErrorRetryPeriodSeconds server para controlar a quantidade de tempo que as tentativas secundárias de retomar a sincronização inicial. Se o secundário não puder retomar com êxito o processo de sincronização inicial durante o período de tempo configurado, ele selecionará uma nova fonte íntegra do conjunto de réplicas e reiniciará o processo de sincronização inicial desde o início.

Antes do MongoDB 4.4, o secundário reiniciaria toda a sincronização inicial se encontrasse um erro durante o processo.

Replicação de streaming

A partir do MongoDB 4.4, as fontes de origem de sincronização enviam um fluxo contínuo de entradas de oplog para seus secundários de sincronização.

Antes do MongoDB 4.4, os secundários obtinham lotes de entradas do oplog emitindo uma solicitação para sua fonte de origem de sincronização e aguardando uma resposta. Isso exigia uma viagem de ida e volta de rede para cada lote de entradas de oplog. O MongoDB 4.4 adiciona o parâmetro de inicialização oplogFetcherUsesExhaust para desativar a replicação de streaming e usar o comportamento de replicação mais antigo.

Para obter detalhes, consulte a página Replicação de streaming.

Diretório de rollback

A partir do Mongo 4.4, o diretório de rollback de uma coleção é nomeado como o UUID da coleção, em vez do namespace da coleção; por exemplo,

<dbpath>/rollback/20f74796-d5ea-42f5-8c95-f79b39bad190/removed.2020-02-19T04-57-11.0.bson

Para obter detalhes, consulte Dados de rollback.

Período mínimo de retenção de Oplog

Você pode especificar o número mínimo de horas para preservar uma entrada de oplog em que mongod só remove uma entrada de oplog se ambos os critérios a seguir forem atendidos:

  • O oplog atingiu o tamanho máximo configurado.

  • A entrada do oplog é mais antiga que o número configurado de horas com base no relógio do sistema host.

Por padrão, o MongoDB não define um período mínimo de retenção de oplog e trunca automaticamente o oplog, começando com as entradas mais antigas para manter o tamanho máximo de oplog configurado.

Para configurar o período mínimo de retenção de oplog ao iniciar o mongod,:

Para configurar o período mínimo de retenção de oplog em um mongod em execução, utilize replSetResizeOplog. Definir o período mínimo de retenção do oplog enquanto o mongod está em execução substitui quaisquer valores definidos na inicialização. Você deve atualizar o valor da configuração do arquivo de configuração correspondente ou da opção de linha de comando para persistir essas alterações por meio da reinicialização do servidor.

Importante

O oplog pode crescer sem restrições, de modo a reter as entradas do oplog pelo número de horas configurado. Isto pode resultar na redução ou esgotamento do espaço em disco do sistema devido a uma combinação de alto volume escrita e grande período de retenção.

Dica

Veja também:

Conjunto de réplicas Oplog

slowOpSampleRate Afeta os logs secundários

A partir do MongoDB 4.4, registros lentos do oplog para aplicativos em secundários de conjuntos de réplicas são afetados pela slowOpSampleRate. Nas versões anteriores, o MongoDB registra todas as entradas lentas do oplog, independentemente da taxa de amostragem.

slowOpSampleRate especifica a fração de operações lentas que devem ser analisadas ou registradas.

Os índices são criados simultaneamente em membros do conjunto de réplicas que contêm dados

Observação

Exige featureCompatibilityVersion 4.4+

Cada mongod no conjunto de réplica ou agrupamento fragmentado deve ter featureCompatibilityVersion configurado para pelo menos 4.4 para iniciar construções de índice simultaneamente entre membros do conjunto de réplicas.

Construir índices em um conjunto de réplicas ou cluster particionado é feito simultaneamente em todos os membros do conjunto de réplicas que contêm dados. Para clusters fragmentados, a construção de índices ocorre somente em fragmentos que contêm dados para a coleção que está sendo indexada. O primário requer um número mínimo de membros com dados voting (ou seja, quórum para a confirmação), incluindo ele próprio, que deve concluir a compilação antes de marcar o índice como pronto para uso.

Por padrão, as compilações de índice usam um quórum para a confirmação de todos os nós votantes que possuem dados. Para iniciar uma compilação de índice com um quórum para a confirmação não padrão, o MongoDB 4.4 adiciona o parâmetro commitQuorum a createIndexes ou a seus auxiliares de shell db.collection.createIndex() e db.collection.createIndexes()/

Para modificar o quórum necessário para uma criação de índice em andamento, o MongoDB 4.4 apresenta o novo comando setIndexCommitQuorum.

Consulte Construções de Índice em Ambientes Replicados para obter mais informações.

Alterações na reconfiguração do conjunto de réplicas

Alterações em replSetReconfig

A partir do MongoDB 4.4, o comando replSetReconfig espera até que a maioria dos nós votantes instale a configuração da réplica antes de retornar com sucesso. Um membro votante é qualquer nó de réplica onde members[n].votes é 1, incluindo árbitros. Primeiro, a operação aguarda até que a configuração atual seja confirmada antes de instalar a nova configuração no primário. Em seguida, a operação aguarda até que a maioria dos nós votantes instale a nova configuração antes de retornar com sucesso. Consulte Reconfiguração aguarda até que a maioria dos membros instale a configuração de réplica para obter mais informações.

Por padrão, replSetReconfig aguarda indefinidamente até que a maioria dos nós votantes instale a configuração. O MongoDB 4.4 também adiciona o parâmetro opcional maxTimeMS a replSetReconfig para especificar o tempo máximo de espera até que a operação retorne com sucesso.

A partir do MongoDB 4.4, o comando replSetReconfig permite adicionar ou remover não mais do que 1 voting nós de cada vez. Para adicionar ou remover vários nós votantes, emita uma série de operações replSetReconfig ou rs.reconfig() para adicionar ou remover um nó de cada vez. Consulte a página A reconfiguração pode adicionar ou remover no máximo um nó votante por vez para obter mais informações.

Alterações em replSetGetConfig

O comando replSetGetConfig pode especificar uma nova opção commitmentStatus: true ao ser executado no primário. Ao ser executado com a opção, o comando inclui na saída um campo commitmentStatus. Esse campo de saída indica se a reconfiguração anterior do conjunto de réplicas foi cometida, de modo que o conjunto de réplicas esteja pronto para ser reconfigurado novamente. Para obter mais informações, consulte o comando replSetGetConfig .

Alterações no documento de configuração da réplica

O MongoDB 4.4 adiciona o campo term ao documento de configuração do conjunto de réplicas. Os membros do conjunto de réplica utilizam term e version para obter consenso sobre a configuração de réplica "mais recente". Configurar featureCompatibilityVersion (fCV): "4.4" executa implicitamente um replSetReconfig para adicionar o campo term ao documento de configuração e bloqueia até que a nova configuração se propague para a maioria dos nós do conjunto de réplicas. Da mesma forma, o downgrade para fCV : "4.2" executa implicitamente uma reconfiguração para remover o campo term .

Fonte de sincronização inicial preferida

A partir do MongoDB 4.4, você pode especificar a fonte de sincronização inicial preferencial usando o parâmetro initialSyncSourceReadPreference. Você só pode definir este parâmetro na inicialização mongod usando a configuração do arquivo de configuração setParameter ou a opção de linha de comando --setParameter.

initialSyncSourceReadPreference é compatível com os seguintes modos de preferência de leitura:

Se o conjunto de réplicas tiver desabilitado chaining, o modo de preferência de leitura initialSyncSourceReadPreference padrão será primary.

Você não pode especificar um conjunto de tags ou maxStalenessSeconds para initialSyncSourceReadPreference.

Dica

Veja também:

Seleção inicial da fonte de sincronização

Leituras espelhadas

A partir da versão 4.4, o MongoDB fornece leituras espelhadas para pré-aquecer o cache de membros secundários elegíveis com os dados acessados mais recentemente. Com leituras espelhadas, o primário pode espelhar um subconjunto de operações que recebe e enviá-las para um subconjunto de secundários elegíveis. O pré-aquecimento do cache de um secundário pode ajudar a restaurar o desempenho mais rapidamente após uma eleição.

Observação

A resposta do primário ao cliente não é afetada pelas leituras espelhadas. As leituras espelhadas são operações "fire-and-forget" (autônomas) do primário; ou seja, o primário não aguarda a resposta para as leituras espelhadas.

Parâmetro de leituras espelhadas

O MongoDB 4.4 adiciona o seguinte parâmetro de leituras espelhadas. Você pode definir o parâmetro na inicialização usando a configuração do arquivo de configuração setParameter ou a opção de linha de comando --setParameter ou em tempo de execução com o comando setParameter:

Parâmetro
Descrição

Especifica as configurações samplingRate e maxTimeMS para leituras espelhadas.

{ samplingRate: <float>, maxTimeMS: <int> }

Um samplingRate de 0 desativa leituras espelhadas.

Métricas de leituras espelhadas

O comando serverStatus e seu método shell correspondente mongo db.serverStatus() retornam mirroredReads se você especificar a inclusão do campo na operação:

db.runCommand( { serverStatus: 1, mirroredReads: 1 } )

ou

db.serverStatus( { mirroredReads: 1 } )

Clusters fragmentados

Chaves de fragmento refináveis

Começando em 4.4, MongoDB fornece o comando refineCollectionShardKey . Com o novo comando, você pode refinar a chave de fragmento de uma coleção adicionando um campo ou campos de sufixo à chave existente. O refinamento da chave de fragmento de uma coleção permite uma distribuição de dados mais refinada e pode resolver situações em que a chave existente levou a parte jumbo (ou seja, indivisíveis) devido à cardinalidade insuficiente.

Por exemplo, você pode ter uma coleção orders existente com a chave de fragmento { customer_id: 1 }. Você pode alterar a chave de fragmento adicionando um campo de sufixo order_id à chave de fragmento para que { customer_id: 1, order_id: 1 } se torne a nova chave de fragmento, permitindo a distribuição de dados pelos campos customer_id e order_id.

Para usar o comando refineCollectionShardKey, o cluster fragmentado deve ter a versão de compatibilidade de recursos (fcv) do 4.4. Para mais informações, consulte o comando refineCollectionShardKey.

Observação

Depois de refinar a chave de fragmento, talvez nem todos os documentos da coleção tenham o(s) campo(s) de sufixo. Para preencher o(s) campo(s) de chave de fragmento ausente(s), consulte Campos de chave de fragmento ausentes.

Antes de refinar a chave de fragmento, certifique-se de que todos ou a maioria dos documentos na coleção tenham os campos de sufixo, se possível, para evitar a necessidade de preencher o campo posteriormente.

Nas versões anteriores, depois de selecionar uma chave de fragmento, você não pode modificá-la.

Importante

Chaves de fragmento ausentes

Com a capacidade de refinar uma chave de fragmento com um sufixo, pode ser que nem todos os documentos na coleção tenham os campos de sufixo. A partir da versão 4.4 os documentos em uma coleção fragmentada podem não ter os campos de chave de fragmento. Em versões anteriores, os campos de chave de fragmento devem existir em todos os documentos de uma coleção fragmentada. Para obter detalhes, consulte Campos de chave de fragmento ausentes.

Leituras cobertas

Para minimizar as latências, as instâncias mongos, por padrão, podem utilizar leituras de hedge. Com leituras distribuídas, as instâncias mongos podem encaminhar operações de leitura para vários membros por cada fragmento consultado e retornar resultados do primeiro respondente por fragmento. Por padrão, as instâncias mongos suportam o uso de leituras distribuídas. Para desativar o suporte de uma instância mongos para leituras distribuídas, defina o parâmetro readHedgingMode para mongos.

As leituras distribuídas são especificadas por operação como parte da preferência de leitura. As preferências de leitura nãoprimary são compatíveis com leituras distribuídas. A preferência de leitura nearest especifica a leitura distribuída por padrão.

Para mais informações, veja:

Parâmetros de leitura distribuída

Parâmetro
Descrição
Ativa ou desativa a compatibilidade com instâncias mongos para leituras distribuídas.
Especifica o limite máximo de tempo (em milissegundos) para a leitura adicional enviada para distribuir uma operação de leitura.

Opção de leitura distribuída para preferência de leitura

Para especificar uma preferência de leitura como leitura distribuída, o MongoDB 4.4 apresenta a Opção de leitura distribuída. Para configurar usando um driver MongoDB, consulte a documentação da API sobre a preferência de leitura do driver.

Os seguintes métodos de shell mongo podem aceitar opções de hedge para habilitar a leitura protegida para a preferência de leitura especificada:

Métricas de leitura distribuída

O comando serverStatus e seu método shell mongo correspondente db.serverStatus() retornam hedgingMetrics.

balancerCollectionStatus Comando

O MongoDB 4.4 fornece o comando balancerCollectionStatus e o assistente de shell mongo sh.balancerCollectionStatus() que retornam informações sobre se as partes de uma coleção fragmentada estão balanceados (ou seja, não precisa ser movido) a partir do momento em que o comando é executado ou precisa ser movido. Com o comando, os usuários podem verificar se a criação e a migração da parte inicial foram concluídas.

Procedimento de inicialização aprimorado mongos

Começando com MongoDB 4.4, mongos adiciona o seguinte novo comportamento de inicialização padrão:

  • mongos carrega previamente a tabela de roteamento de um cluster fragmentado na inicialização, em vez de fazê-lo sob demanda para a primeira conexão de cliente de entrada.

  • mongos pré-prepara seu pool de conexões para fragmentar hosts na inicialização, em vez de fazer isso sob demanda para conexões de clientes de entrada.

Esse comportamento resulta em um atendimento mais rápido das conexões iniciais do cliente após uma instância mongos ser iniciada ou reiniciada. Em particular, isso permite que sites que empregam múltiplas instâncias mongos as reiniciem ou adicionem outras, sem que as solicitações iniciais do cliente para essas instâncias precisem aguardar o estabelecimento da conexão.

O pré-carregamento da tabela de roteamento e a pré-preparação do pool de conexões são habilitados por padrão.

MongoDB 4.4 adiciona os seguintes parâmetros para controlar esse comportamento:

Aprimoramentos nas atualizações de tabela de roteamento

A execução de flushRouterConfig não é mais necessária após a execução dos comandos movePrimary ou dropDatabase. Esses dois comandos agora atualizam automaticamente a tabela de roteamento de um cluster fragmentado conforme o necessário quando executado. A emissão manual do comando flushRouterConfig ainda é recomendada nos casos descritos em Considerações sobre flushRouterConfig.

Chaves de fragmento com hash compostas

A partir do MongoDB 4.4, você pode fragmentar uma coleção usando uma chave de fragmento composta com um único campo hash. Antes do 4.4, o MongoDB não suportava chaves de fragmento compostas com um campo com hash.

A fragmentação composta com hash oferece suporte a recursos como fragmentação por zonas, onde o prefixo (ou seja, o primeiro) campo ou campos sem hash suportam faixas de zona, enquanto o campo com hash suporta uma distribuição mais uniforme dos dados fragmentados. Por exemplo, a operação a seguir fragmenta uma coleção em uma chave de fragmento com hash compostas que oferece suporte à fragmentação por zonas:

sh.shardCollection(
  "examples.compoundHashedCollection",
  { "fieldA" : 1, "fieldB" : 1, "fieldC" : "hashed" }
)

A fragmentação com hash composta também é compatível com chaves de fragmento com um prefixo hash para resolver problemas de distribuição de dados relacionados ao aumento monotônico de campos. Por exemplo, a operação a seguir fragmenta uma coleção em uma chave de fragmento com hash composta em que o campo com hash é o prefixo da chave de fragmento:

sh.shardCollection(
  "examples.compoundHashedCollection",
  { "_id" : "hashed", "fieldA" : 1}
)

Dica

Veja também:

Melhorias na resiliência de failover de migração de partes

A partir do MongoDB 4.4, as alterações a seguir melhoram as migrações em partes e a resiliência da limpeza de documentos órfãos durante o failover:

  • Os intervalos de parte que aguardam limpeza após uma migração de partes agora são mantidos na coleção config.rangeDeletions e replicados em todo o fragmento. No caso de um failover, o novo primário do fragmento lê os documentos na coleção config.rangeDeletions e retoma a exclusão dos intervalos correspondentes. O documento que descreve um intervalo aguardando limpeza é excluído da coleção config.rangeDeletions depois que o intervalo é excluído.

  • O comando cleanupOrphaned não exclui mais documentos órfãos de um fragmento. Em vez disso, cleanupOrphaned aguarda a exclusão de documentos órfãos que estão programados para serem excluídos de um fragmento.

Defina o parâmetro disableResumableRangeDeleter como true no primário de um fragmento para pausar a exclusão do intervalo no fragmento.

Melhorias gerais em clusters fragmentados

Verificações de consistência do índice

A partir do MongoDB 4.4, o servidor de configuração primário, por padrão, verifica inconsistências de índice nos fragmentos de coleções fragmentadas. O comando serverStatus retorna o campo shardedIndexConsistency para relatar inconsistências de índice quando executado no servidor de configuração primário.

Para configurar as verificações de consistência do índice, o MongoDB fornece os seguintes parâmetros:

Parâmetro
Descrição
Ativar ou desativar as verificações de consistência do índice.
O intervalo no qual o primário do servidor de configuração verifica a consistência do índice de coleções fragmentadas.

removeShard Operações simultâneas

A partir do MongoDB 4.4, você pode ter mais de uma operação removeShard em andamento.

Nas versões anteriores, removeShard retornará um erro se outra operação removeShard estiver em andamento.

Limite da chave de fragmento

A partir da versão 4.4, O MongoDB remove o limite de 512-byte no tamanho da chave de fragmento. Para MongoDB 4.2 e anterior, uma chave de fragmento não pode exceder 512 bytes.

Resultados parciais

A partir de 4.4, se os comandos find ou getMore subsequentes retornarem resultados parciais devido à indisponibilidade do(s) fragmento(s) de query, a saída incluirá um sinalizador booleano partialResultsReturned.

Migração de partes jumbo

Para blocos muito grandes para serem migrados, a partir do MongoDB 4.4:

  • Uma nova configuração do balanceador attemptToBalanceJumboChunks permite que o balanceador migre as partes grandes demais para serem movidas, desde que as partes não sejam rotuladas como jumbo. Consulte Intervalos de equilíbrio que excedem o limite de tamanho para saber detalhes.

  • O comando moveChunk pode especificar uma nova opção forceJumbo para permitir a migração de partes que são muito grandes para serem movidas. As partes podem ser rotuladas de jumbo ou não.

Atualização aprimorada do cache do catálogo

A partir de 4.4, se houver uma parte obsoleta, o cache do catálogo só será atualizado quando os roteadores acessarem um fragmento que anteriormente tinha ou atualmente tem essa parte.

Antes do MongoDB 4.4, qualquer chunk obsoleto fazia com que toda a distribuição de chunk de uma collection fosse marcada como obsoleta e forçava todos os roteadores que entravam em contato com o shard a atualizar o cache do catálogo de shards. O MongoDB 4.4 adiciona o parâmetro de inicialização enableFinerGrainedCatalogCacheRefresh para desabilitar a atualização do cache do catálogo somente para um shard direcionado e usar o comportamento de atualização do cache do catálogo mais antigo. O parâmetro enableFinerGrainedCatalogCacheRefresh é padronizado como true.

Dividir automaticamente a coleção system.sessions

A partir da versão 4.4 (e 4.2.7), o MongoDB faz a divisão automática da coleção system.sessions em pelo menos 1024 partes e distribui as partes uniformemente entre os fragmentos no cluster.

Projeção

A partir do MongoDB 4.4, como parte de tornar a projeção find() e findAndModify() consistentes com o estágio $project da aggregation,

  • A projeção find() e findAndModify() pode aceitar expressões de agregação e sintaxe de agregação, inclusive o uso de literais e variáveis de agregação. Com o uso de expressões de agregação e sintaxe, você pode projetar novos campos ou projetar campos existentes com novos valores.

  • A projeção find() e findAndModify() pode especificar campos incorporados usando o formulário aninhado (por exemplo, { field: { nestedfield: 1 } }), bem como notação de ponto. Nas versões anteriores, só é possível usar a notação de ponto.

Para mais informações, veja:

Dica

Veja também:

Restrições de colisão de caminho

$meta Operador

$meta Suporte a palavras-chave

A partir do MongoDB 4.4, o operador $meta adiciona suporte para recuperar os metadados indexKey . Os metadados indexKey servem apenas para fins de depuração e não para lógica de aplicativo. Consulte $meta para obter mais informações.

{ $meta: "textScore" } Uso com find()

A partir da versão 4.4, O MongoDB faz as seguintes alterações { $meta: "textScore" } quando usado com db.collection.find():

  • Você deve especificar o operador $text no predicado da consulta para usar { $meta: "textScore" }.

    Observação

    $text fornece recursos de query de texto para sistemas autogerenciados (não Atlas). Para dados hospedados no MongoDB Atlas, o MongoDB oferece uma solução de query de texto completo aprimorada, Atlas Search.

  • É possível classificar os documentos resultantes por relevância de pesquisa (ou seja, { $meta: "textScore" }) sem também ter que projetar o textScore.

    In earlier versions, to include { $meta: "textScore" } expression in the sort(), you must also include the same expression in the projection.

  • Se você incluir a expressão { $meta: "textScore" } na projeção e na classificação, ou seja, db.collection.find(<$text search>, <projection>).sort(<sort>), os documentos de projeção e classificação poderão ter nomes de campo diferentes para a expressão.

    In previous versions of MongoDB, if you include the { $meta: "textScore" } in both the projection and sort, you must specify the same field name in both places.

Para obter mais informações, consulte Metadados de pontuação de texto $meta: "textScore". Para obter exemplos de projeções e classificações "textScore" , consulte Exemplos de pontuação de relevância.

Consulte: Metadados de pesquisa de texto { $meta: "textScore" } Requisito de consulta

Transações

A partir do MongoDB 4.4 com a versão de compatibilidade do recurso (fcv) "4.4", você pode criar coleções e índices dentro de uma transação multidocumento, a menos que a transação seja de gravação.

Ao criar uma coleta dentro de uma transação:

Ao criar um índice dentro de uma transação:

  • Você pode criar um índice em uma coleção inexistente. A coleção é criada como parte da operação.

  • Você pode criar um índice em uma nova coleção vazia criada anteriormente na mesma transação.

  • O método db.collection.createIndex() falha se for executado em uma coleção do sistema.

Para obter mais detalhes, consulte a página Criar coleções e índices em uma transação.

MongoDB 4.4 adiciona um novo parâmetro shouldMultiDocTxnCreateCollectionAndIndexes que pode habilitar (padrão) ou desabilitar a criação de coleções e índices dentro de uma transação. Ao configurar o parâmetro para um cluster fragmentado, defina o parâmetro em todos os fragmentos.

Para a criação explícita de uma coleção ou de um índice em uma transação, o nível de preocupação com a leitura da transação deve ser "local". A criação explícita é por meio de:

Comando
Método

Dica

Veja também:

Classificação

$sort Mudanças

A partir do MongoDB 4.4, o método sort() agora usa o mesmo algoritmo de classificação do estágio de agregação $sort. Com essa alteração, as consultas que executam sort() em campo que contêm valores duplicados têm muito mais chances de resultar em ordens de classificação inconsistentes para esses valores.

Para garantir consistência de classificação ao utilizar sort() em valores duplicados, inclua um campo adicional em sua classificação que contenha exclusivamente valores exclusivos.

Isso pode ser feito facilmente adicionando o campo _id à sua classificação.

Consulte Consistência de classificação para obter mais informações.

Melhorias na segurança

Nova ferramenta de validação Kerberos mongokerberos

O MongoDB Enterprise 4.4 fornece uma nova ferramenta mongokerberos para validar a configuração do Kerberos de sua plataforma para uso com o MongoDB e para testar a autenticação de cliente de ponta a ponta por meio do Kerberos. Quando executado, o mongokerberos retorna um relatório indicando quaisquer problemas encontrados e fornece possíveis conselhos para resolvê-los. mongokerberos está disponível apenas no MongoDB Enterprise.

OCSP

A partir da versão 4.4, o MongoDB habilita, por padrão, o uso do OCSP (Online Certificate Status Protocol) para verificar se houve revogação do certificado. O uso do OCSP elimina a necessidade de baixar uma Certificate Revocation List (CRL) periodicamente e reiniciar o mongod / mongos com a CRL atualizada.

Nas versões 4.0 e 4.2, o uso do OCSP está disponível somente pelo uso do system certificate store no Windows ou macOS.

Dica

Veja também:

TLS/SSL (Criptografia de transporte)

Grampeamento OCSP/Grampeamento obrigatório

Como parte do suporte ao OCSP, o MongoDB 4.4 suporta no Linux:

Parâmetros OCSP

O MongoDB 4.4 adiciona os parâmetros OCSP a seguir. Você pode definir esses parâmetros na inicialização usando a configuração do arquivo de configuração setParameter ou a opção de linha de comando --setParameter:

Parâmetro
Descrição
Habilita ou desabilita o suporte do OCSP.
Especifica o número de segundos de espera antes de atualizar a resposta de status do OCSP grampeada.
Especifica o número máximo de segundos que a instância mongod / mongos deve aguardar para receber a resposta de status OCSP para seus certificados.
Especifica o número máximo de segundos que o mongod / mongos deve aguardar a resposta do OCSP ao verificar certificados de cliente.

Avisos de expiração dos certificados x.509

A partir do MongoDB 4.4, mongod / mongos registra um aviso na conexão se o certificado x.509 apresentado expirar dentro de 30 dias a partir do relógio do sistema mongod/mongos. Especificamente, as seguintes conexões com um mongod ou mongos podem acionar avisos de expiração de certificado x.509:

A mensagem de log de aviso assemelha-se ao seguinte:

<Timestamp> W NETWORK [connection] Peer certificate <Certificate Subject Name> expires...

Considere renovar proativamente os certificados do cliente x.509 que estão prestes a expirar para garantir a conectividade contínua com o cluster.

O MongoDB 4.4 adiciona o parâmetro tlsX509ExpirationWarningThresholdDays para controlar o limite de aviso de expiração de certificado. Defina o parâmetro para 0 para desativar o aviso. Para a documentação completa, consulte tlsX509ExpirationWarningThresholdDays.

TLS 1.3 Suporte

No CentOS 8 e RHEL 8, MongoDB 4.4 (bem como as versões 4.2, 4.0 e 3.6) suportam TLS1.3.

Saídas de mapeamento de usuário para DN na rede ou falhas de autenticação

Um mongod, mongos ou mongoldap retorna um erro se um dos mapeamentos de nome diferenciado (DN) não puder ser avaliado devido a falhas de rede ou de autenticação no servidor LDAP.

O mongod, mongos ou mongoldap rejeita a solicitação de conexão e não verifica os mapeamentos restantes, se houver.

Para especificar o usuário para o mapeamento DN, consulte:

Registro estruturado

A partir do MongoDB 4.4, as instâncias do mongod / mongos agora geram todas as mensagens de log no formato JSON estruturado. As entradas de log são escritas como uma série de pares de chave-valor, em que cada chave indica um tipo de campo de mensagem de log (por exemplo, "gravidade") e cada valor correspondente registra as respectivas informações de log para esse tipo de campo, por exemplo, "informational".

Isso inclui a saída de log enviada para o arquivo, syslog e destinações de log stdout(saída padrão), bem como a saída do comando getLog.

Anteriormente, as entradas de registro eram geradas como texto simples.

As seguintes mensagens de log no formato JSON indicam que um mongod está atendendo e pronto para conexões:

{"t":{"$date":"2020-05-18T20:18:13.533+00:00"},"s":"I",  "c":"NETWORK",  "id":23015,   "ctx":"listener","msg":"Listening on","attr":{"address":"127.0.0.1"}}
{"t":{"$date":"2020-05-18T20:18:13.533+00:00"},"s":"I",  "c":"NETWORK",  "id":23016,   "ctx":"listener","msg":"Waiting for connections","attr":{"port":27001,"ssl":"off"}}

O registro estruturado com pares de valores-chave permite uma análise eficiente de registros por meio de ferramentas automatizadas ou serviços de ingestão de registros e torna a análise programática de logs mais fácil e eficaz.

Ao trabalhar com o log estruturado do MongoDB, o utilitário de linha de comando jqde terceiros é uma ferramenta útil que permite a impressão fácil e bonita de entradas de registro e a poderosa correspondência e filtragem baseadas em chaves.

jq é um analisador JSON de código aberto, e está disponível para Linux, Windows e macOS.

Para obter mais informações sobre log estruturado, incluindo uma análise detalhada dos componentes de entrada de log, bem como exemplos de análise de linha de comando, consulte Mensagens de log.

Suporte a múltiplas senhas LDAP

A partir do MongoDB 4.4, o comando ldapQueryPassword setParameter aceita uma string ou um array de strings. Se definida como um array, cada senha é testada até que uma seja bem-sucedida. Isso pode ser usado para executar uma substituição da senha da conta LDAP sem tempo de inatividade para o MongoDB.

Suporte a plataformas

Plataformas adicionadas

O MongoDB 4.4 adiciona suporte para as seguintes plataformas:

Plataformas removidas

O MongoDB 4.4 remove o suporte para as seguintes plataformas:

  • Amazon Linux 2013.03

  • RHEL 6 / CentOS 6 / Oracle 6 na arquitetura s390x

  • Windows 7 / Servidor 2008 R2

  • Windows 8 / Servidor 2012

  • Windows 8.1 / Servidor 2012 R2

  • macOS 10.12

Consulte o Suporte da plataforma para obter a lista completa de plataformas e arquiteturas suportadas no MongoDB 4.4.

mongo shell

O Mongo Shell oferece suporte às credenciais do AWS IAM para clusters do Atlas

A partir do MongoDB 4.4, o mongo shell permite o uso de credenciais AWS IAM para autenticar em um cluster do MongoDB Atlas que foi configurado para autenticação AWS IAM.

A autenticação dessa maneira usa o novo MONGODB-AWS authentication mechanism e requer que você forneça um ID de chave de acesso da AWS e uma chave de acesso secreta, que podem ser especificadas na string de conexão ou na linha de comando por meio das opções --username e --password.

Além disso, se você estiver usando um token de sessão da AWS para autenticação com credenciais temporárias ao usar uma solicitação AssumeRole ou ao trabalhar com recursos da AWS que especificam esse valor, como Lambda, você pode fornecer esse token de sessão da AWS na string de conexão usando o valor AWS_SESSION_TOKEN authMechanismProperties ou na linha de comando por meio da opção --awsIamSessionToken.

Como alternativa, se o ID da chave de acesso da AWS, a chave de acesso secreta ou o token de sessão estiverem definidos em sua plataforma usando suas respectivas variáveis de ambiente da AWS IAM, o mongo shell usará esses valores de variáveis de ambiente para autenticar; você não precisa especificá-los na string de conexão.

Na página Opções de autenticação para strings de conexão, é possível encontrar informações sobre o uso dessa função. Na página Conexão a um Atlas Cluster com o MONGODB-AWS, há exemplos.

Ferramentas

Migração para o Projeto de Ferramentas de Banco de Dados MongoDB

A partir do MongoDB 4.4, a documentação das seguintes ferramentas foi migrada para o projeto MongoDB Database Tools:

As Database Tools do MongoDB usam o Apache, versão 2.0. Veja mongodb/mongo-tools para o código-fonte.

Observação

Para obter documentação das versões anteriores das ferramentas listadas, consulte a versão em questão do manual do servidor do MongoDB.

Links rápidos da documentação mais antiga:

Nova mongokerberos ferramenta de validação Kerberos

O MongoDB Enterprise 4.4 fornece uma nova ferramenta mongokerberos para validar a configuração do Kerberos de sua plataforma para uso com o MongoDB e para testar a autenticação de cliente de ponta a ponta por meio do Kerberos. Quando executado, o mongokerberos retorna um relatório indicando quaisquer problemas encontrados e fornece possíveis conselhos para resolvê-los. mongokerberos está disponível apenas no MongoDB Enterprise.

Consulte a página de referência mongokerberos para obter mais informações.

mongoreplay Removido do pacote MongoDB

A partir do MongoDB 4.4, mongoreplay é removido da embalagem MongoDB. mongoreplay e sua documentação relacionada são migrados para o mongodb-labs projeto GitHub. Os projetos em mongodb-labs são experimentais e não são oficialmente suportados pelo MongoDB.

Links rápidos para documentação antiga

Ferramentas do MongoDB Database não empacotadas com Windows MSI

O instalador MSI do Windows para as edições Community e Enterprise não inclui as ferramentas do banco de dados MongoDB (mongoimport, mongoexport, etc). Para fazer download e instalar as ferramentas do banco de dados MongoDB no Windows, consulte Instalação das ferramentas do banco de dados MongoDB.

Se você dependia do MongoDB 4.2 ou do instalador MSI anterior para instalar o Database Tools junto com o MongoDB Server, agora deve baixar o Database Tools separadamente.

Drivers

Novos drivers

  • O driver oficial do MongoDB Rust já está disponível.

  • O driver oficial do MongoDB Swift já está disponível.

Índices

Índices compostos com hash

O MongoDB 4.4 é compatível com a criação de índices compostos com um único campo com hash. O MongoDB 4.2 e anteriores eram compatíveis apenas com índices com hash de campo único.

A operação a seguir cria um índice composto com hash em country e _id:

db.examples.createIndex( { "country" : 1, "_id" : "hashed" } )

Índices compostos com hash exigem FeatureCompatibilityVersion definido como 4.4.

Dica

Veja também:

Chaves de fragmento com hash compostas

Índices ocultos

A partir da versão 4.4, O MongoDB adiciona a capacidade de ocultar ou exibir índices do planejador de query. Um índice oculto do planejador de query não é avaliado como parte da seleção do plano de query.

Ao ocultar um índice do planejador, você pode avaliar o possível impacto de descartar um índice sem ter que descartar o índice. Se o impacto for negativo, você poderá exibir o índice em vez de ter que recriar um índice descartado. E como os índices são totalmente mantidos enquanto estão ocultos, os índices ocultos ficam imediatamente disponíveis para uso quando são exibidos.

Para obter detalhes, consulte Índices ocultos.

Para oferecer suporte a índices ocultos, o MongoDB apresenta:

dropIndexes Você pode abortar construções de índice em andamento

Se um índice especificado para dropIndexes ainda estiver compilando, dropIndexes tentará abortar a compilação em andamento. Abortar a compilação de um índice tem o mesmo efeito que descartar o índice criado. Antes do MongoDB 4.4, dropIndexes retornaria um erro se a coleção tivesse alguma compilação de índice em andamento. Esse comportamento também se aplica aos assistentes de shell db.collection.dropIndex() e db.collection.dropIndexes().

Para descartar um índice específico de um conjunto de construções em andamento relacionadas, espere até que as construções do índice sejam concluídas e especifique esse índice como dropIndexes ou seus assistentes de shell.

Para obter uma documentação mais completa, consulte:

drop() Você pode abortar construções de índice em andamento

O método db.collection.drop() e o comando drop abortam qualquer criação de índice em andamento na coleção de destino antes de descartar a coleção.

Para conjuntos de réplicas ou conjuntos de réplicas de estilhaços, abortar um índice no primário não anula simultaneamente as compilações de índice secundário. O MongoDB tenta abortar as compilações em andamento para os índices especificados no primário e, se for bem-sucedido, cria uma entrada de oplog abort associada. Os membros secundários com compilações replicadas em andamento aguardam uma entrada de oplog de confirmação ou abortamento do primário antes de confirmar ou abortar a compilação do índice.

Para conjuntos de réplicas ou conjuntos de réplicas de estilhaços, abortar um índice no primário não anula simultaneamente as compilações de índice secundário. O MongoDB tenta abortar as compilações em andamento para os índices especificados no primário e, se for bem-sucedido, cria uma entrada de oplog abort associada. Os membros secundários com compilações replicadas em andamento aguardam uma entrada de oplog de confirmação ou abortamento do primário antes de confirmar ou abortar a compilação do índice.

dropDatabase Você pode abortar construções de índice em andamento

O método db.dropDatabase() e o comando dropDatabase abortam quaisquer construções de índice em andamento que tenham sido criadas em coleções no banco de dados de destino antes de descartar o banco de dados. Abortar a construção de um índice tem o mesmo efeito que descartar o índice criado.

Dica

Veja também:

O índice se baseia nas coleções preenchidas

Descontinuação do geoHaystack índice e geoSearch comando

O MongoDB 4.4 descontinua o índice geoHaystack e o comando geoSearch. Use um índice2d com $geoNear ou $geoWithin.

Comandos removidos

O MongoDB remove o(s) seguinte(s) comando(s) e mongo assistente(s) de shell:

Comando removido
Auxiliar removido
Alternativas
cloneCollection
db.cloneCollection()
planCacheListPlans
PlanCache.getPlansByQuery()
See also $planCacheStats Changes.
planCacheListQueryShapes
PlanCache.listQueryShapes()
See also $planCacheStats Changes.

Networking

Suporte para TCP Fast Open

A partir do MongoDB 4.4, o mongod e omongos suportam conexões TCP Fast Open (TFO) por padrão. Para usar TFO, o cliente e as máquinas do host mongod/mongos devem suportar e ativar as conexões TFO:

Windows

Os seguintes sistemas operacionais Windows são compatíveis com TFO:

  • Microsoft Windows Server 2016 ou posterior.

  • Microsoft Windows 10 com atualização nº 1607 ou posterior.

macOS
O macOS 10.11 (El Capitan) e versões mais recentes suportam TFO
Linux

Sistemas operacionais Linux executando o Linux Kernel 3.7 ou posterior podem oferecer suporte a conexões TFO de entrada.

Sistemas operacionais Linux executando Linux Kernel 4.11 ou posterior podem suportar conexões TFO de entrada e saída.

Defina o valor de /proc/sys/net/ipv4/tcp_fastopen para ativar o suporte para conexões TFO de entrada e/ou saída:

  • Defina como 1 para ativar somente conexões TFO de saída

  • Defina como 2 para ativar somente conexões TFO de entrada.

  • Defina como 3 para ativar conexões TFO de entrada e saída.

MongoDB 4.4 adiciona os seguintes parâmetros para controlar o TFO:

Parâmetro
Descrição

Padrão: true (habilitado)

Habilita ou desabilita o suporte para conexões TFO de entrada para o mongod/mongos

Padrão: true (habilitado)

Somente sistema operacional Linux

Ativa ou desativa o suporte para conexões TFO de saída do mongod/mongos.

Padrão: 1024

Controle o tamanho da fila de conexões TFO pendentes.

O MongoDB 4.4 adiciona os seguintes contadores à saída de serverStatus e db.serverStatus():

Contador
Descrição

Linux only

Indica o suporte do kernel para TFO.

Indica suporte do sistema operacional para conexões TFO de entrada.
Indica o suporte do sistema operacional para conexões TFO de saída.
Indica o número total de conexões TFO de entrada aceitas para o mongod / mongos desde a última vez que a instância mongod/mongos foi iniciada.

A discussão completa sobre o TFO está fora do escopo desta documentação. Para obter mais informações sobre TFO, comece com os seguintes recursos externos:

Melhorias gerais

Limite de classificação de bloqueio aumentado

Se o MongoDB não puder usar um índice ou índices para obter a ordem de classificação para uma determinada operação cursor.sort(), o MongoDB deverá executar uma classificação de bloqueio nos dados. Uma classificação de bloqueio indica que o MongoDB deve consumir e processar todos os documentos de entrada para a classificação antes de retornar os resultados. As classificações de bloqueio não bloqueiam operações simultâneas na coleção ou no banco de dados.

Antes do MongoDB 4.4, o MongoDB retornava um erro se uma block sort exigisse mais de 32 megabytes de memória do sistema. A partir do MongoDB 4.4, as operações de block sort aumentam o limite de memória do sistema a ser usado para a operação de classificação para 100 megabytes Para operações de block sort que exigem mais de 100 megabytes de memória do sistema, o MongoDB retorna um erro a menos que a query especifique cursor.allowDiskUse() (novidade no MongoDB 4.4).

Para saber mais sobre classificações e uso de índices, consulte a página Classificações e índices.

Dica

Veja também:

find Pode usar arquivos temporários para oferecer suporte a classificações grandes não indexadas

O MongoDB 4.4 adiciona uma nova opção allowDiskUse ao comando find. Com allowDiskUse: true, a operação pode usar arquivos temporários no disco ao processar uma operação de classificação não indexada ("block sort") que exceda o limite de memória de 100 megabytes. Antes do MongoDB 4.4, uma operação find com uma classificação block sort falhava se excedesse o limite de memória ao processar a classificação.

Para o método de shell db.collection.find() com cursor.sort(), o MongoDB 4.4 adiciona o modificador de cursor cursor.allowDiskUse().

allowDiskUse e cursor.allowDiskUse() não terão efeito se o MongoDB puder satisfazer a classificação usando um índice ou se a classificação de bloqueio exigir menos de 100 megabytes de memória.

Para instruções sobre como ativar o allowDiskUse para queries emitidas por meio de um driver do MongoDB, consulte a documentação do driver compatível com o MongoDB 4.4 de sua preferência.

Dica

Veja também:

Limite de namespace da coleção

A partir do MongoDB 4.4,

O limite de comprimento do namespace para coleções e visualizações não fragmentadas é de 255 bytes e 235 bytes para coleções fragmentadas. Para uma coleção ou visualização, o namespace inclui o nome do banco de dados, o separador de ponto (.) e o nome da coleção/visualização (por exemplo, <database>.<collection>).

Informações sobre o rendimento dos dados de validação

Os comandos $currentOp e currentOp incluem informações dataThroughputAverage e dataThroughputLastSecond para validar operações em andamento.

As mensagens de registro para validar operações incluem informações dataThroughputAverage e dataThroughputLastSecond.

Dica

Veja também:

db.collection.validate() Mudança de parâmetro

compact Mudança de comportamento

Bloqueio

Começando no MongoDB 4.4, compact bloqueia apenas as seguintes operações de metadados:

compact não bloqueia Operações CRUD do MongoDB para o banco de dados em que está operando no momento.

Anteriormente, compact bloqueava todas as operações do banco de dados em que estava operando, inclusive operações CRUD do MongoDB, e portanto só era adequado para uso durante os períodos de manutenção agendados.

force Opção

A partir do MongoDB 4.4, o sinalizador force força compact a ser executado no primário em um conjunto de réplicas.

Anteriormente, a opção force , quando definida como true habilitava compact para ser executada no primário em um conjunto de réplicas e, se definida como false, retornava um erro ao ser executada em um primário.

Dica

Veja também:

compactar

mongod --repair Mudança de comportamento

A partir do MongoDB 4.4, o mongod --repair recria todos os índices para o seguinte:

  • Coleções com inconsistências entre os dados da coleta e um ou mais índices.

  • Coleções recuperadas e modificadas.

Nas versões anteriores do MongoDB, a opção mongod --repair reconstruía todos os índices de todas as coleções.

serverStatus Alteração de saída

Alteração do nome do campo

serverStatus retorna flowControl.locksPerKiloOp em vez de flowControl.locksPerOp.

Novos campos

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

serverStatus Alteração na saída das estatísticas de fragmentação

shardingStatistics.numHostsTargeted reporta o número de fragmentos direcionados por operações CRUD e comandos de aggregation. Ele incrementa a métrica relevante de localização, inserção, atualização, exclusão ou agregação com cada operação em um cluster.

replSetGetStatus Alteração de saída

replSetGetStatus retorna os seguintes novos campos:

db.auth() pode solicitar senha

A partir do MongoDB 4.4, o método mongo do shell db.auth(<username>, <password>) solicita a senha se você não a passar ou o método passwordPrompt() para o <password>.

Suporte para $natural Classificar em Visualizações

Você pode especificar uma classificação $natural ao executar uma operação find em uma exibição.

Suporte para geração de acompanhamento de diagnóstico

Para instâncias do MongoDB em execução no Linux:

  • Quando os processos mongod e mongos recebem um sinal SIGUSR2, os detalhes do backtrace são adicionados aos registros de cada thread do processo.

  • Os detalhes de backtrace mostram as chamadas de função para o processo, que podem ser usadas para diagnósticos e fornecidas ao Suporte do MongoDB, se necessário.

A funcionalidade de backtrace está disponível para estas arquiteturas:

  • x86_64

  • arm64 (a partir do MongoDB 5.0.10 e 6.0)

Para mais informações, consulte Gerar um Backtrace.

Relatórios FTDC com reconhecimento de contêineres

A partir do MongoDB 4.4, O FTDC agora informa os dados de utilização de um mongod em execução em um contêiner a partir da perspectiva do contêiner, em vez do sistema operacional do host. Consulte Captura de dados de diagnóstico em tempo integral para obter mais informações.

Aviso de inicializaçãoatualizado ulimit

A partir do MongoDB 4.4, mongod registra um aviso de inicialização se o valor ulimit configurado de uma plataforma para o número de arquivos abertos for inferior a 64000. Anteriormente, um aviso só seria registrado se esse valor estivesse abaixo de 1000. Consulte Configurações ulimit recomendadas para obter mais informações.

Novo replanReason campo de saída do analisador de banco de dados

O MongoDB 4.4 adiciona o campo replanReason à saída do profiler de banco de dados e às mensagens de log de diagnóstico. O campo replanReason contém o motivo pelo qual o sistema de query removeu um plano em cache.

dbStats e collStats saída

O comando dbStats e seu assistente de shell mongo db.stats() retornam:

O comando collStats , seu assistente de shell mongo db.collection.stats() e o estágio de agregação $collStats retornam:

Dicais disponíveis para comandos de banco de dados adicionais

A partir do MongoDB 4.4, os seguintes comandos de banco de dados podem aceitar um argumento hint para especificar o índice a ser usado:

Consulte:

Execução JavaScript em mongos

A partir do MongoDB 4.4, o MongoDB permite a execução de JavaScript em instâncias do mongos. Para desabilitar a execução de JavaScript em uma instância do mongos:

Versões anteriores do MongoDB não permitem a execução de JavaScript em instâncias mongos.

Preocupação de leitura e preocupação de gravação padrão global

Observação

Exige featureCompatibilityVersion 4.4+

Cada mongod no conjunto de réplica ou cluster fragmentado deve ter featureCompatibilityVersion configurado para pelo menos 4.4 para configurar a preocupação de leitura ou gravação padrão global.

A partir do MongoDB 4.4, conjuntos de réplicas e clusters fragmentados suportam a definição de configurações globais padrão para preocupação de leitura e preocupação de gravação. Os clientes que não especificam explicitamente uma determinada configuração de preocupação de gravação ou de leitura herdam a configuração padrão global correspondente.

Para configurar a preocupação de leitura ou gravação padrão global, o MongoDB adiciona o comando administrativo setDefaultRWConcern. Para conjuntos de réplicas, emita o comando contra o membro principal. Para clusters fragmentados, emita o comando em um mongos.

Para recuperar as configurações globais padrão de leitura ou gravação, o MongoDB adiciona o comando administrativo getDefaultRWConcern.

Read concern do Provenance

A partir do MongoDB 4.4, os objetos de preocupação de leitura podem incluir um campo provenance , indicando onde a preocupação de leitura se originou.

A tabela a seguir mostra os possíveis valores de read concern provenance e seu significado:

Proveniência
Descrição
clientSupplied
O read concern foi especificado no aplicativo.
customDefault
A read concern originou-se de um valor padrão personalizado definido. Consulte setDefaultRWConcern.
implicitDefault
A read concern a originou-se do servidor na ausência de todas as outras especificações de read concern.

Se uma operação de leitura for registrada ou perfilada, a entrada da operação conterá o objeto de preocupação de leitura, incluindo o campo provenance.

O MongoDB não recomenda especificar o campo provenance em solicitações para o servidor. Este campo deve ser usado apenas para fins de diagnóstico.

Escreva a preocupação com a proveniência

A partir do MongoDB 4.4, os objetos de preocupação de gravação podem incluir um campo provenance, indicando a origem da preocupação de gravação.

A tabela a seguir mostra os possíveis valores de write concern provenance e seu significado:

Proveniência
Descrição
clientSupplied
A preocupação de gravação foi especificada no aplicativo.
customDefault
A preocupação de gravação originou-se de um valor padrão personalizado definido. Consulte setDefaultRWConcern.
getLastErrorDefaults
A preocupação de gravação originada do campo settings.getLastErrorDefaults do conjunto de réplicas.
implicitDefault
A preocupação de gravação originou-se do servidor na ausência de todas as outras especificações de preocupação de gravação.

Se uma operação de gravação for registrada ou perfilada, a entrada da operação conterá o objeto de preocupação de gravação, incluindo o campo provenance.

O MongoDB não recomenda especificar o campo provenance em solicitações para o servidor. Este campo deve ser usado apenas para fins de diagnóstico.

currentOp Saída

Novos parâmetros de conexão KMIP para mongod

MongoDB 4.4 A Enterprise apresenta duas novas configurações para aprimorar a conexão inicial com um servidor KMIP, como parte da autenticação Kerberos:

Tentativas de conexão

Para controlar o número de vezes que mongod tenta novamente uma falha na conexão inicial com o servidor KMIP:

Tempo limite de conexão

Para controlar o tempo limite, em milissegundos, para aguardar a resposta inicial do servidor KMIP antes de desistir ou tentar novamente:

Essas configurações estão disponíveis apenas no MongoDB Enterprise.

Nova opção de inicialização para mongod

A nova opção de inicialização processUmask para mongod permite definir permissões por meio de umask para grupos e outros usuários quando honorSystemUmask está definido como false.

mapReduce Ignora a verbose opção

A partir do MongoDB 4.4, o comando mapReduce e o método shell db.collection.mapReduce() ignoram a opção verbose.

explain Suporte para mapReduce

A partir do MongoDB 4.4, você pode usar o comando explain ou o método de shell db.collection.explain() para visualizar os resultados de mapReduce ou db.collection.mapReduce().

Melhorias nos explain resultados

A partir da versão 4.4:

Dica

Veja também:

Explique os resultados.

comment Opção disponível para todos os comandos de banco de dados

A partir do MongoDB 4.4, todos os comandos de banco de dados suportam a especificação de um campo comment, da seguinte forma:

Exemplo

db.runCommand( { <command> , "comment" : <any BSON type> })

Depois de definido, o comentário aparece junto com os registros do comando nos seguintes locais:

Um comentário deve ser um objeto BSON válido (string, número inteiro, array etc.).

Melhorias no operador posicional $

A partir do MongoDB 4.4, ao usar o operador posicional $, você pode especificar diferentes campos de array entre o documento de query e o documento de projeção.

Por exemplo, se você inserir o seguinte documento em uma collection:

db.foo.insertOne( { a: [ "one", "two", "three" ], b: [ 1, 2, 3 ] } )

A partir do MongoDB 4.4, você pode usar a seguinte query para projetar somente o primeiro elemento do campo b para um documento que corresponda à query especificada no campo a:

db.foo.findOne( { a: "one" }, { "b.$": 1 } )

Importante

Para garantir o comportamento esperado, as arrays usadas no documento de query e o documento de projeção devem ter o mesmo comprimento. Se as arrays tiverem comprimentos diferentes, a operação poderá apresentar erros em determinados cenários.

Nas versões anteriores do MongoDB, essa operação falha porque o campo da array que está sendo limitado deve aparecer no documento de consulta.

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 das alterações na compatibilidade, consulte a página Alterações na compatibilidade no MongoDB 4.4.

Procedimentos de atualização

Importante

Versão de compatibilidade de recursos

Para atualizar da implantação 4.2, a implantação 4.2 deve ter featureCompatibilityVersion definida como 4.2. Para verificar a versão:

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

Para obter detalhes sobre como verificar e configurar o featureCompatibilityVersion, bem como informações sobre outros pré-requisitos/considerações para upgrades, consulte as instruções de upgrade individuais:

Se precisar de orientação sobre como atualizar para a versão 4.4, 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 fazer o downgrade de uma série 4.4 para uma implantação da série 4.2. No entanto, fazer outro downgrade da implantação da série 4.2 para uma implantação da série 4.0 não é suportado.

Download

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

Dica

Veja também:

Problemas conhecidos

Na versão
Problemas
Status
4.4.0
SERVIDOR-45042: A instalação MSI do MongoDB Server tanto para Community quanto Enterprise não contém mais binários para as Ferramentas do MongoDB Database. Para obter mais informações, consulte Alterações de ferramentas.
Não resolvido
4.4.0
SERVIDOR-49694: Em um cluster fragmentado, leituras distribuídas ou nearest não podem ser encaminhadas para uma réplica próxima ao fragmento.
Corrigido na versão 4.4.1
4.4.0
WT-6623: Defina o ID do arquivo de nível de conexão na verificação do arquivo de recuperação.
Corrigido na versão 4.4.1

Relatar um problema

Para relatar um problema, consulte a página https://github.com/mongodb/mongo/wiki/Submit-Bug-Reports e veja instruções para registrar um ticket do JIRA no servidor MongoDB ou um em um dos projetos relacionados.

Voltar

Registro de alterações