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 o seu sistema depender de recursos impactados por um Advisory crítico, atualize para a versão de patch mais recente disponível.

Emitir
Versões afetadas
WT-7426
4.4.5
WT-7984
4.4.8
WT-7995
4.4.2 - 4.4.8
WT-10461
4.4.0 - 4.4.18 (arquiteturas de sistema ARM64 ou POWER)
WT-10551
4.4.8 - 4.4.21 (Backups incrementais no Ops Manager ou clusters do Cloud Manager)
SERVIDOR-58936
4.4.7

Lançamentos de patches

4.4.29 - 28 de fevereiro de 2024

Importante

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

Devido ao CVE-2024-1351, no MongoDB 4.4 antes de 4.4.29, em certas configurações de --tlsCAFile e CAFile, o 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 reduzir efetivamente as garantias de segurança fornecidas pelo TLS e conexões abertas que deveriam ter sido fechadas devido à falha na validação do certificado. Esse problema afeta as seguintes versões do servidor MongoDB:

  • 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 incorreta do certificado

4.4.28 - 18 janeiro de 2024

4.4.27 - 3 janeiro de 2024

4.4.26 - Nov 27 de 2023

Problemas corrigidos:

4.4.25 - Set 29, 2023

Problemas corrigidos:

  • SERVIDOR-76299 Relatório writeConflicts em serverStatus nos secundários

  • SERVIDOR-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

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

  • SERVIDOR- As71627 informações atualizadas da rota de collection em cache bloquearão severamente todas as solicitações do cliente quando um cluster com 1 milhões de chunks

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

  • WT-8570 Não aumente o ID mais antigo durante a recuperação

  • WT-10449 Não salve a cadeia de atualização 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 - jul 13 de 2023

4.4.22 - 18 maio de 2023

4.4.21 - abril 27 de 2023

Problemas corrigidos:

4.4.20 - abril 10 de 2023

Problemas corrigidos:

4.4.19 - 27 fevereiro de 2023

Problemas corrigidos:

4.4.18 - Nov 21 de 2022

Problemas corrigidos:

4.4.17 - Set 28, 2022

Problemas corrigidos:

4.4.16 - Ago 19 de 2022

Problemas corrigidos:

4.4.15 - 21 junho de 2022

Problemas corrigidos:

4.4.14 - 9 maio de 2022

Problemas corrigidos:

4.4.13 - 7 março, 2022

Problemas corrigidos:

4.4.12 - 21 janeiro de 2022

Problemas corrigidos:

4.4.11 - Dec. 30, 2021

Problemas corrigidos:

4.4.10 - 15 outubro, 2021

Problemas corrigidos:

4.4.9 - Set 21, 2021

Problemas corrigidos:

4.4.8 - Ago 4 de 2021

Problemas corrigidos:

4.4.7 - jul 16 de 2021

Problemas corrigidos:

4.4.6 - 10 maio de 2021

Problemas corrigidos:

4.4.5 - abril 8 de 2021

Problemas corrigidos:

4.4.4 - 16 fevereiro de 2021

Problemas corrigidos:

  • SERVIDOR-48471: Os índices de hash podem ser marcados incorretamente como multikey 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}}

  • SERVIDOR-52919: Compactação de fio não ativada para initial sync

  • WT-7109: Manter opções de configuração não suportadas para 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 - Nov 18 de 2020

Problemas corrigidos:

4.4.1 - Set 9, 2020

Problemas corrigidos:

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

  • SERVIDOR-48641: Impasse devido ao MigrationDestinationManager aguardando preocupação de gravação com check-out da sessão

  • SERVIDOR-49546: setFCV para 4.4 deve inserir tarefas de exclusão de intervalo 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 roteadas para uma réplica próxima ao shard.

  • SERVIDOR-50137:3 O MongoDB falha com falha invariante devido a entradas de oplog geradas em .4

  • SERVIDOR-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: Defina 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 Full Time Diagnostic Data Capture (FTDC) em mongod ou mongos falhar, ele encerra o processo de origem. Para evitar as falhas mais comuns, confirme se o usuário que executa mongod/mongos tem permissões para criar o diretório FTDC diagnostic.data 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 customizadas

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 customizadas:

Com a adição desses novos operadores, você pode usar a aggregation 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 redução de mapa também podem ser reescritas usando outros estágios do pipeline de agregação, como $group, $merge etc., sem exigir funções personalizadas.

Para mais informações, consulte Map-Reduce to Aggregation Pipeline.

Novos operadores de aggregation

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

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

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

$replaceOne
Substitui a primeira instância de uma string correspondente em uma determinada entrada.
$replaceAll
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 saída para uma collection em um banco de dados diferente. Em versões anteriores, $out só pode gerar saída para uma collection no mesmo banco de dados onde a aggregation é 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
estilhaço
Nome do shard, se aplicável.
especificações
Documento de especificação do índice
construção
Uma bandeira booleana que indica se o índice está sendo construído no momento.

$merge

Começando no MongoDB 4.4:

  • $merge pode gerar saída para uma collection em um banco de dados diferente. Em versões anteriores, $merge só pode gerar saída para uma collection no mesmo banco de dados onde a aggregation é 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 collection que está sendo agregada. Você também pode gerar saída para uma collection 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 executada pelo $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 um documento de argumento. Fornecer este 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

Resumable Initial Sync

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, a secundária 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 Replicação de streaming.

Diretório de rollback

A partir de Mongo 4.4, o diretório de reversão de uma coleção é nomeado em homenagem ao UUID da coleção em vez do espaço de nomes 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 reversão.

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 somente 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 Atinge registros secundários

A partir do MongoDB 4.4, os registros de aplicativos oplog lentos nos secundários do conjunto de réplicas são afetados pelo slowOpSampleRate. Nas versões anteriores, o MongoDB registrava 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 construídos simultaneamente em membros do conjunto de réplicas portadoras de 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 quorum de confirmação de todos os membros votantes portadores de dados. Para iniciar uma construção de índice com um commit quorum não padrão, MongoDB 4.4 adiciona o parâmetro commitQuorum a createIndexes ou seus ajudantes de shell db.collection.createIndex() e db.collection.createIndexes().

Para modificar o quorum necessário para uma construção de índice em andamento, 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 aguarda até que a maioria dos membros votantes instale a configuração de réplica antes de retornar com êxito. Um membro votante é qualquer membro de réplicas em que 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 principal. A operação então aguarda até que a maioria dos membros votantes instale a nova configuração antes de retornar com sucesso. Consulte A reconfiguração aguarda até que uma maioria dos membros instale a configuração da réplica para obter mais informações.

replSetReconfig espera indefinidamente que a maioria dos membros votantes instale a configuração por padrão. MongoDB 4.4 também adiciona o parâmetro opcional maxTimeMS a replSetReconfig para especificar o tempo máximo de espera pelo retorno bem-sucedido da operação.

A partir do MongoDB 4.4, o comando replSetReconfig permite adicionar ou remover não mais do que 1 voting membro de cada vez. Para adicionar ou remover vários membros votantes, emita uma série de operações replSetReconfig ou rs.reconfig() para adicionar ou remover um membro de cada vez. Consulte A reconfiguração pode adicionar ou remover no máximo um membro 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 primary. 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 mais informações, consulte o comando replSetGetConfig .

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

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". Definindo 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 membros 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 preferencial

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 esse parâmetro na inicialização mongod , usando a definição do arquivo de configuração setParameter ou a opção de linha de comando --setParameter .

initialSyncSourceReadPreference suporta 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 da primário para o cliente não é afetada pelas leituras do espelho. As leituras espelhadas são operações do tipo "fire-and-forget" do primary; ou seja, o primário não aguarda a resposta para as leituras espelhadas.

Parâmetro de leituras espelhadas

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 no tempo de execução com o comando setParameter :

Parâmetro
Descrição
mirrorReads

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 de shell mongo correspondente 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 Shard refináveis

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

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

Para usar o comando refineCollectionShardKey , o cluster fragmentado deve ter a feature compatibility version (fcv) do 4.4. Para mais informações, consulte o comando refineCollectionShardKey .

Observação

Depois de refinar a chave de shard, pode ser que nem todos os documentos na collection tenham o(s) campo(s) de sufixo. Para preencher o(s) campo(s) de chave de Shard ausente(s), consulte Campos de chave de Shard ausente(s).

Antes de refinar a chave de shard, 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, após selecionar uma chave de shard, não é possível modificar a chave de shard.

Importante

Chaves de fragmentação ausentes

Com a capacidade de refinar uma chave de shard 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 fragmentada. Em versões anteriores, os campos principais de fragmento devem existir em todos os documentos para uma coleta fragmentada. Para obter detalhes, consulte Campos de chave de shard ausentes.

Leituras cobertas

Para minimizar as latências, as instâncias mongos , por padrão, podem usar leituras de hedge. Com leituras protegidas, as instâncias mongos podem rotear as operações de leitura para vários membros por cada fragmento consultado e retornar os 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 o mongos.

As leituras com hedge são especificadas por operação como parte da preferência de leitura. As preferências de leitura nãoprimary suportam leituras protegidas. A Preferência de leitura nearest especifica a leitura protegida por padrão.

Para mais informações, veja:

Parâmetros de leitura cobertos

Parâmetro
Descrição
readHedgingMode
Habilita ou desabilita o suporte da instância mongos para leituras distribuídas.
maxTimeMSForHedgedReads
Especifica o limite de tempo máximo (em milissegundos) para a leitura adicional enviada para proteger uma operação de leitura.

Opção de leitura coberta para preferência de leitura

Para especificar a leitura distribuída para uma preferência de leitura, MongoDB 4.4 introduz a opção de leitura distribuída. Para configurar o uso de um driver do MongoDB, consulte a documentação da API de preferência de leitura do driver.

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

Métricas de leitura distribuídas

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

balancerCollectionStatus Comando

MongoDB 4.4 fornece o comando balancerCollectionStatus e o método auxiliar de shell mongo sh.balancerCollectionStatus() que retornam informações sobre se os blocos de uma coleção fragmentada estão balanceados (ou seja, não precisam ser movidos) 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 inicial do chunk foram concluídas.

Procedimento de inicialização mongos aprimorado

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

  • mongos pré-carrega a tabela de roteamento de um cluster fragmentado na inicialização, em vez de fazer isso sob demanda para a primeira conexão do cliente recebida.

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

Este comportamento resulta em uma manutenção mais rápida das conexões iniciais do cliente depois que uma instância mongos é iniciada ou reiniciada. Em particular, isso permite que sites que empregam várias instâncias mongos as reiniciem conforme necessário ou adicionem novos, sem solicitações iniciais do cliente para as instâncias que precisam aguardar o estabelecimento da conexão.

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

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

Atualizações aprimoradas da tabela de roteamento

A execução 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 necessário quando executados. A emissão manual do comando flushRouterConfig ainda é recomendada nos casos descritos em Considerações sobre flushRouterConfig.

Hashed Shard Keys composta

A partir do MongoDB 4.4, você pode fragmentar uma collection usando uma chave de shard composta com um único campo hasheado. Antes de 4.4, o MongoDB não suportava chaves de shard compostas com um campo hashed.

A fragmentação hasheada composta suporta recursos como a fragmentação de zona , em que o ou os campos não hasheados de prefixo (ou seja, primeiro) suportam faixas de zonas, enquanto o campo hasheado suporta uma distribuição mais uniforme dos dados fragmentados. Por exemplo, a operação a seguir fragmenta uma collection em uma chave de shard com hash composto que oferece suporte à fragmentação por zonas:

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

A fragmentação hasheada composta também oferece suporte a chaves de shard com um prefixo hasheado para resolver problemas de distribuição de dados relacionados a campos que aumentam monotonicamente Por exemplo, a operação a seguir fragmenta uma collection em uma chave de shard com hash composto onde o campo hasheado é o prefixo da chave de shard:

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

Dica

Veja também:

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

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

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

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

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

Melhorias gerais nos clusters fragmentados

Verificações de Consistência de Índices

A partir do MongoDB 4.4, o servidor de configuração primário, por padrão, verifica se há inconsistências de índice nos fragmentos para 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
enableShardedIndexConsistencyCheck
Habilite ou desabilite as verificações de consistência do índice.
shardedIndexConsistencyCheckIntervalMS
O intervalo no qual o servidor de configuração primário verifica a consistência do índice de coleções fragmentadas.

Operações removeShard simultâneas

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

Em versões anteriores, o removeShard retorna um erro se outra operação do removeShard estiver em andamento.

Limite da chave de shard

A partir da versão 4.4, o MongoDB remove o limite de 512-byte no tamanho da chave de shard. Para MongoDB 4.2 e anterior, uma chave de shard 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) analisado(s), a saída incluirá uma bandeira booleana partialResultsReturned.

Migração de chunk do Jumbo

Para chunks que são muito grandes para serem migrados, começando no MongoDB 4.4:

  • Uma nova configuração de balanceador attemptToBalanceJumboChunks permite que o balanceador migre os blocos grandes demais para serem movidos, desde que os blocos não sejam rotulados como jumbo. Consulte Intervalos de equilíbrio que excedem o limite de tamanho para detalhes.

  • O comando moveChunk pode especificar uma nova opção forceJumbo para permitir a migração de chunks que são muito grandes para serem movidos. Os pedaços podem ou não ser rotulados como jumbo.

Atualização aprimorada do cache do catálogo

A partir de 4.4, se houver um chunk obsoleto, o cache do catálogo só será atualizado quando os roteadores acessarem um shard que anteriormente tinha ou atualmente tem esse chunk.

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), MongoDB divide automaticamente a coleção system.sessions em pelo menos 1024 blocos e distribui os blocos 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 aggregation e sintaxe de aggregation, incluindo o uso de literais e variáveis de aggregation. 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 embarcados usando o formulário aninhado; por exemplo, { field: { nestedfield: 1 } } , bem como notação de ponto. Nas versões anteriores, você só pode 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 são 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 de query para usar { $meta: "textScore" }.

  • Você pode classificar os documentos resultantes por sua relevância de pesquisa, ou seja, { $meta: "textScore" }, sem também ter que projetar textScore.

    Em versões anteriores, para incluir a expressão { $meta: "textScore" } no sort(), você também deve incluir a mesma expressão na projeção.

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

    Nas versões anteriores do MongoDB, se você incluir o { $meta: "textScore" } tanto na projeção quanto na classificação, deverá especificar o mesmo nome de campo em ambos os lugares.

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

Consulte: Metadados da Pesquisa de Texto { $meta: "textScore" } Requisitos de query

Transações

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

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 coleta é criada como parte da operação.

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

  • O método db.collection.createIndex() falha se executado em uma collection do sistema.

Para obter mais detalhes, consulte Criar collections 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 collection e índice dentro de uma transação. Ao configurar o parâmetro para um agrupamento 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
create
db.createCollection()
createIndexes
db.collection.createIndex()
db.collection.createIndexes()

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 que o estágio de agregação $sort . Com essa alteração, as queries que executam um sort() em campos que contêm valores duplicados têm muito mais probabilidade de resultar em ordens de classificação inconsistentes para esses valores.

Para garantir a consistência da classificação ao usar sort() em valores duplicados, inclua um campo adicional em sua classificação que contenha exclusivamente valores únicos.

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

MongoDB Enterprise 4.4 fornece uma nova ferramenta mongokerberos para validar a configuração do Kerberos da sua plataforma para uso com o MongoDB e para testar a autenticação do cliente de ponta a ponta por meio do Kerberos. Quando executado, mongokerberos retorna um relatório indicando quaisquer problemas encontrados e fornece conselhos em potencial 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 a revogação do certificado. O uso do OCSP elimina a necessidade de baixar periodicamente um Certificate Revocation List (CRL) 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/grampeamento obrigatório do OCSP

Como parte do suporte a OCSP, o MongoDB 4. O 4 é compatível com o seguinte no Linux:

Parâmetros do OCSP

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

Parâmetro
Descrição
ocspEnabled
Habilita ou desabilita o suporte do OCSP.
ocspValidationRefreshPeriodSecs
Especifica o número de segundos de espera antes de atualizar a resposta de status do OCSP grampeada.
tlsOCSPStaplingTimeoutSecs
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.
tlsOCSPVerifyTimeoutSecs
Especifica o número máximo de segundos que o mongod / mongos deve aguardar a resposta do OCSP ao verificar certificados de cliente.

x.509 Avisos de gatilho de certificados próximos da expiração

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

A mensagem do registro de avisos é semelhante à seguinte:

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

Considere renovar proativamente o cliente x.509 certificados próximos da expiração para garantir conectividade contínua com o cluster.

MongoDB 4.4 adiciona o parâmetro tlsX509ExpirationWarningThresholdDays para controlar o limite de aviso de expiração do certificado. Configure o parâmetro para 0 para desabilitar o aviso. Para obter a documentação completa, consulte tlsX509ExpirationWarningThresholdDays.

TLS 1. Suporte 3

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 em falhas de rede ou autenticação

Um mongod, mongos ou mongoldap retorna um erro se um dos mapeamentos de usuário para Nome Distinto (DN) não puder ser avaliado devido a falhas de rede ou 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. As instâncias 4, mongod / mongos agora geram todas as mensagens de registro no formato JSON estruturado. As entradas de registro são escritas como uma série de pares de chave-valor, onde cada chave indica um tipo de campo de mensagem de registro, como "gravidade", e cada valor correspondente registra as informações de registro associadas para esse tipo de campo, como "informacional".

Isso inclui a saída de registro enviada para o arquivo, syslog e stdout (padrão de saída) destinos de registro, 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á escutando 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 chave-valor permite a análise eficiente do registro por ferramentas automatizadas ou serviços de ingestão de registro e torna a análise programática de registro mais fácil e mais avançada.

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 o registro estruturado, incluindo um exame detalhado dos componentes de entrada do registro, bem como exemplos de análise de linha de comando, consulte Mensagens do registro.

Suporte a múltiplas senhas LDAP

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

Suporte a plataformas

Plataformas adicionadas

MongoDB 4. O 4 adiciona suporte para as seguintes plataformas:

Plataformas removidas

MongoDB 4.4 remove 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 Suporte à Plataforma para obter a lista completa de plataformas e arquiteturas suportadas no MongoDB 4.4.

mongo shell

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

A partir do MongoDB 4.4, o mongo shell suporta o uso de credenciais AWS IAM para autenticar em um cluster do MongoDB Atlas que foi configurado para autenticação do 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 connection string ou na linha de comando por meio de --username e --password opções.

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

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 usa esses valores de variáveis de ambiente para autenticar; você não precisa especificá-los na connection string.

Consulte Opções de autenticação de string de conexão para uso e Conexão com um cluster do Atlas usando MONGODB-AWS para obter exemplos.

Ferramentas

Projeto de 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 Ferramentas do Banco de Dados MongoDB utilizam a Licença Apache, Versão 2.0. Consulte mongodb/mongo-tools para o código fonte.

Observação

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

Links rápidos para documentação antiga:

Nova ferramenta de validação Kerberos mongokerberos

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

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

mongoreplay Removido da embalagem 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 do 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 de Banco de Dados MongoDB Não Embaladas com Windows MSI

O instalador do Windows MSI para as edições Community e Enterprise não inclui as Ferramentas do Banco de Dados MongoDB (mongoimport, mongoexport, etc.). Para baixar e instalar as Ferramentas do Banco de Dados MongoDB no Windows, consulte Instalando as Ferramentas do Banco de Dados MongoDB.

Se você estava contando com o MongoDB 4.2 ou instalador MSI anterior para instalar as Ferramentas do Banco de Dados junto com o Servidor MongoDB, agora você deve baixar as Ferramentas do Banco de Dados separadamente.

Drivers

Novos drivers

Índices

Índices compostos com hash

MongoDB 4.4 adiciona suporte para a criação de índices compostos com um único campo hasheado. MongoDB 4.2 e anteriores suportavam apenas índices com hash de campo único.

A seguinte operação cria um índice composto hasheado 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:

Hashed Shard Keys composta

Índices ocultos

A partir da versão 4.4, o MongoDB adiciona a capacidade de ocultar ou exibir índices do planejador de queries. 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 da eliminação de um índice sem precisar eliminá-lo. Se o impacto for negativo, você poderá exibir o índice em vez de ter que recriar um índice descartado. E, como 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 introduz:

dropIndexes Pode cancelar construções de índice em andamento

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

Para eliminar um índice específico de um conjunto de compilações em andamento relacionadas, aguarde até que as compilações do índice sejam concluídas e especifique esse índice para dropIndexes ou para seus ajudantes de shell.

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

drop() Pode cancelar construções de índice em andamento

O método db.collection.drop() e o comando drop abortam quaisquer construções de índice em andamento na collection de destino antes de descartar a collection.

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 Pode cancelar construções de índice em andamento

O método db.dropDatabase() e o comando dropDatabase abortam quaisquer construções de índice em andamento em collection no reconhecimento de data center de destino antes de descartar o reconhecimento de data center. Abortar a construção de um índice tem o mesmo efeito que eliminar o índice criado.

Dica

Veja também:

O índice se baseia nas coleções preenchidas

Descontinuação do índice geoHaystack e comando geoSearch

MongoDB 4.4 substitui o índice geoHaystack e o comando geoSearch . Em vez disso , use um índice d2 com $geoNear ou $geoWithin .

Comandos removidos

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

Comando removido
Auxiliar removido
Alternativas
cloneCollection
db.cloneCollection()
planCacheListPlans
PlanCache.getPlansByQuery()
Consulte também $planCacheStats Alterações.
planCacheListQueryShapes
PlanCache.listQueryShapes()
Consulte também $planCacheStats Alterações.

Networking

Suporte para TCP Fast Open

Começando com MongoDB 4.4, mongod e mongos suportam conexões TCP Fast Open (TFO) por padrão. O TFO requer tanto o cliente quanto o suporte das máquinas host mongod/mongos e habilita o TFO:

Windows

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

  • Microsoft Windows Server 2016 ou posterior.

  • Microsoft Windows 10 Update 1607 ou posterior.

macOS
macOS 10.11 (El Capitan) e posterior suportam TFO
Linux

Sistemas operacionais Linux executando Linux Kernel 3.7 ou posterior pode suportar conexões TFO de entrada.

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

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

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

  • Defina como 2 para habilitar 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
tcpFastOpenServer

Padrão: true (Ativado)

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

tcpFastOpenClient

Padrão: true (Ativado)

Somente sistema operacional Linux

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

tcpFastOpenQueueSize

Padrão: 1024

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

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

Contador
Descrição
network.tcpFastOpen.kernelSetting

Linux only

Indica o suporte do kernel para TFO.

network.tcpFastOpen.serverSupported
Indica o suporte do sistema operacional para conexões TFO de entrada.
network.tcpFastOpen.clientSupported
Indica o suporte do sistema operacional para conexões TFO de saída.
network.tcpFastOpen.accepted
Indica o número total de conexões TFO de entrada aceitas para o mongod / mongos desde a última vez que o mongod/mongos foi iniciado.

Uma 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 bloqueante 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 retornou um erro se uma operação de ordenador bloqueante exigisse mais de 32 megabytes de memória do sistema. Iniciando no MongoDB 4.4, o bloqueio das operações de classificação aumenta o limite de memória do sistema a ser usado na operação de classificação para 100 megabytes. Para operações de classificação bloqueante que exigem mais de 100 megabytes de memória do sistema, o MongoDB retorna um erro a menos que a query especifique cursor.allowDiskUse() (novo no MongoDB 4.4).

Para obter mais informações sobre classificação e uso de índices, consulte Uso de classificação e índice.

Dica

Veja também:

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

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 ("bloqueio") que excede o limite de memória de megabyte 100 . Antes do MongoDB 4.4, uma operação find com uma classificação de bloqueio falhará se exceder o limite de memória durante o processamento da classificação.

Para o método de shell db.collection.find() com cursor.sort(), 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 obter instruções sobre como ativar o allowDiskUse para queries emitidas por um driver do MongoDB, consulte a documentação do MongoDB 4 de sua preferência.4-driver compatível.

Dica

Veja também:

Limite de namespace da coleção

A partir do MongoDB 4.4,

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

Informações de taxa de transferência de 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() Parameter change

compact Mudança de comportamento

Bloqueio

A partir do 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 atualmente.

Anteriormente, o compact bloqueava todas as operações do banco de dados em que estava operando, incluindo operações CRUD do MongoDB e, portanto, era apropriado apenas para uso durante os períodos de manutenção programados.

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 reconstrói todos os índices para o seguinte:

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

  • Coleções salvas e modificadas.

Nas versões anteriores do MongoDB, a opção mongod --repair reconstruiu todos os índices para todas as collections.

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 do resultado das estatísticas de fragmentação

shardingStatistics.numHostsTargeted reporta o número de shards 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 a 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 shell db.auth(<username>, <password>) solicita a senha se você não passar a senha 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 visualização.

Suporte para geração de rastreamento 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 (começando no MongoDB 5.0.10, e 6.0)

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

Relatórios de FTDC com reconhecimento de contêiner

A partir do MongoDB 4.4, o FTDC agora relata dados de utilização para um mongod em execução em um container da perspectiva do container, 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ção ulimit atualizado

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

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

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

dbStats e collStats saída

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

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

Sugestão disponível para comandos de banco de dados adicionais

A partir do MongoDB 4.4, os seguintes comandos do 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 mongos . Para desabilitar a execução do JavaScript em uma instância mongos :

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

Preocupação com leitura e 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 o read ou write concern padrão global.

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

Para configurar o read ou write concern padrão global padrão, o MongoDB adiciona o comando administrativo setDefaultRWConcern . Para conjuntos de réplicas, emita o comando contra o nó primário . Para clusters fragmentados, emita o comando de um mongos.

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

Read concern do Provenance

A partir do MongoDB 4.4, os objetos de read concern podem incluir um campo provenance , indicando onde a read concern 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 read concern, 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 write concern podem incluir um campo provenance , indicando a origem da write concern.

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 analisada, 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 O Enterprise apresenta duas novas definições de configuração para aprimorar a conexão inicial com um servidor KMIP, como parte da autenticação Kerberos:

Novas tentativas de conexão

Para controlar o número de vezes que o mongod tenta novamente uma conexão inicial com falha no 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 processUmask opção de inicialização mongod do para permite a você definir permissões por umask para grupos e outros usuários quando está definido honorSystemUmask como false.

mapReduce Ignora a opção verbose

Começando com MongoDB 4.4, o comando mapReduce e o método db.collection.mapReduce() shell ignoram a opção verbose .

explain Suporte para mapReduce

Começando com MongoDB 4.4, você pode usar o comando explain ou o método db.collection.explain() shell para visualizar os resultados de mapReduce ou db.collection.mapReduce().

Melhorias nos resultados explain

A partir da versão 4.4:

Dica

Veja também:

Explicar resultados.

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

A partir do MongoDB 4.4, todos os comandos do 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 ao lado dos 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.

Em versões anteriores do MongoDB, esta operação falha porque o campo de array que está sendo limitado deve aparecer no documento de query.

Alterações que afetam a compatibilidade

Algumas alterações podem afetar a compatibilidade e podem exigir ação do usuário. Para obter uma lista detalhada das mudanças de compatibilidade, consulte Alterações de compatibilidade no MongoDB 4.4.

Procedimentos de atualização

Importante

Versão de compatibilidade de recursos

Para atualizar do 4.2 sistema, o 4.2 sistema deve ter featureCompatibilityVersion definido como 4.2. Para verificar a versão:

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

Para obter detalhes específicos sobre a verificação e configuração do featureCompatibilityVersion , bem como informações sobre outros pré-requisitos/considerações para atualizações, consulte as instruções de atualização individuais:

Se precisar de orientação sobre como atualizar para 4.4, os serviços profissionais do MongoDB oferecem suporte à atualização da versão principal para ajudar a garantir uma transição sem interrupções para seu aplicativo 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 downgrade de um 4.4- série a 4. Sistema 2-série. No entanto, desatualizando ainda mais 4.2sistema -série em um 4.0-series não é suportada.

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 do servidor MongoDB MSI para Community e Enterprise não contém mais binários para as Ferramentas de Banco de Dados MongoDB. Para mais informações, consulte Alterações de ferramentas.
Não resolvido
4.4.0
SERVIDOR-49694: Em um cluster fragmentado, nearest leituras ou leituras distribuídas não podem ser roteadas para uma réplica próxima ao shard.
Corrigido em 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 em 4.4.1

Relatar um problema

Para relatar um problema, consulte https://github.com/mongodb/mongo/wiki/Submit-Bug-Reports para obter instruções sobre como arquivar um ticket do JIRA para o servidor MongoDB ou um dos projetos relacionados.

← 5.0 Registro de alterações
Alterações de compatibilidade no MongoDB 4.4 →

Nesta página