Página inicial do Docs → Desenvolver aplicações → Manual do MongoDB
Alterações de compatibilidade no MongoDB 4.4
Nesta página
O seguinte 4.4 alterações podem afetar a compatibilidade com versões mais antigas do MongoDB.
Comandos removidos
O MongoDB remove o(s) seguinte(s) comando(s) e o(s) assistente de shell mongo
:
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. |
Parâmetros removidos
O MongoDB remove o seguinte parâmetro do servidor:
Parâmetro removido | Descrição |
---|---|
failIndexKeyTooLong | MongoDB 4.4 remove o parâmetro failIndexKeyTooLong . Este parâmetro foi preterido no 4.2 como MongoDB com featureCompatibilityVersion (fCV) versão 4.2+ não impõe mais um Limite de Chave de Índice. |
Mudanças em ferramentas
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.
Conjuntos de réplicas
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.
replSetGetStatus
Alterações no campo de saída
O comando replSetGetStatus
e seu ajudante de shell mongo
rs.status()
remove os seguintes campos obsoletos de sua saída:
Campo removido | Alternativa |
---|---|
replSetGetStatus.syncingTo | Use syncSourceHost em vez disso. |
members[n].syncingTo | Use members[n].syncSourceHost em vez disso. |
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
.
Restrições de sincronização inicial nas operações
Para executar em um membro do conjunto de réplicas, as operações a seguir exigem que o membro esteja no estado PRIMARY
ou SECONDARY
.
Se o membro estiver em outro estado, como STARTUP2
, os erros de operação.
Valores de getLastErrorDefaults
personalizados obsoletos
A partir da versão 4.4, o MongoDB descontinua a especificação de um valor settings.getLastErrorDefaults
diferente do padrão de { w: 1, wtimeout: 0 }
. MongoDB 4.4 honra qualquer valor de write concern que você especificar, no entanto, as versões futuras do MongoDB podem não honrar valores diferentes do padrão. Em vez disso, use o comando setDefaultRWConcern
para definir a configuração padrão de preocupação com leitura ou gravação para um conjunto de réplicas ou cluster fragmentado.
Alterações na compatibilidade de projeções
Definir campos para novos valores
A partir do MongoDB 4.4, find e projeção findAndModify()
podem aceitar expressões de aggregation e sintaxe de aggregation.
Com o uso de expressões de agregação e sintaxe, incluindo o uso de literais e variáveis de agregação, se você especificar um literal (distinto de um número ou de um booleano) para o valor do campo de projeção, o campo será projetado com o novo valor.
Por exemplo, considere um inventário de collection com documentos que contêm um campo status
:
db.inventory.insertOne( { _id: 1, item: "postcard", status: "A", instock: [ { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ] })
A partir do MongoDB, 4.4, a operação a seguir projeta os campos status
e instock
com novos valores em vez de seu valor atual:
db.inventory.find( { status: "A" }, { status: "Active", instock: ["blue", "crimson"] } )
Ou seja, a operação retorna o seguinte documento:
{ "_id" : 1, "status" : "Active", "instock" : [ "blue", "crimson" ] }
Em versões anteriores, qualquer valor de especificação (com exceção do valor zero/falso ou do valor de documento anteriormente não suportado) é tratado como true
para indicar a inclusão do campo com seu valor atual. Ou seja, em versões anteriores, a operação anterior retorna um documento com os campos status
e instock
com seus valores atuais:
{ "_id" : 1, "status" : "A", "instock" : [ { "warehouse" : "B", "qty" : 15 }, { "warehouse" : "C", "qty" : 35 } ] }
$elemMatch
Ordem do campo de projeção
Independentemente da ordenação dos campos no documento, a projeção $elemMatch
de um campo existente retorna o campo após as outras inclusões de campo existentes.
Por exemplo, considere uma collection players
com o seguinte documento:
db.players.insertOne( { name: "player1", games: [ { game: "abc", score: 8 }, { game: "xyz", score: 5 } ], joined: new Date("2020-01-01"), lastLogin: new Date("2020-05-01") } )
A projeção a seguir retorna o campo games
após os outros campos existentes incluídos na projeção, mesmo que, no documento, o campo esteja listado antes dos campos joined
e lastLogin
:
db.players.find( {}, { games: { $elemMatch: { score: { $gt: 5 } } }, joined: 1, lastLogin: 1 } )
Ou seja, a operação retorna o seguinte documento:
{ "_id" : ObjectId("5edef64a1c099fff6b033977"), "joined" : ISODate("2020-01-01T00:00:00Z"), "lastLogin" : ISODate("2020-05-01T00:00:00Z"), "games" : [ { "game" : "abc", "score" : 8 } ] }
Na versão 4.2 e anterior, a projeção $elemMatch
de um campo existente mantém a ordem no documento:
{ "_id" : ObjectId("5edef91e76ddff7d92f118e1"), "games" : [ { "game" : "abc", "score" : 8 } ], "joined" : ISODate("2020-01-01T00:00:00Z"), "lastLogin" : ISODate("2020-05-01T00:00:00Z") }
$slice
da matriz incorporada
A projeção $slice
de uma array em um documento agrupado não retorna mais os outros campos no documento aninhado quando a projeção faz parte de uma projeção de inclusão.
Por exemplo, considere uma collection inventory
com documentos que contêm um campo size
:
{ item: "socks", qty: 100, details: { colors: [ "blue", "red" ], sizes: [ "S", "M", "L"] } }
A operação a seguir projeta o campo _id
(por padrão), o campo qty
e o campo details
apenas com a fatia especificada da array colors
:
db.inventory.find( { }, { qty: 1, "details.colors": { $slice: 1 } } )
Ou seja, a operação retorna o seguinte documento:
{ "_id" : ObjectId("5ee92a6ec644acb6d13eedb1"), "qty" : 100, "details" : { "colors" : [ "blue" ] } }
Se a projeção $slice
fizer parte de uma projeção de exclusão, a operação continuará retornando os outros campos no documento aninhado. Ou seja, a seguinte projeção é uma projeção de exclusão. A projeção exclui o campo _id
e os elementos da array colors
que estão fora da fatia especificada e retorna todos os outros campos.
db.inventory.find( { }, { _id: 0, "details.colors": { $slice: 1 } } )
{ "item" : "socks", "qty" : 100, "details" : { "colors" : [ "blue" ], "sizes" : [ "S", "M", "L" ] } }
A projeção $slice
por si só é considerada uma exclusão.
Em versões anteriores, a projeção $slice
também inclui os outros campos no documento agrupado, independentemente de a projeção ser uma inclusão ou uma exclusão.
Restrições de colisão de caminho
Colisão de caminho: documentos incorporados e seus campos
Não é possível projetar um documento incorporado com qualquer um de seus campos.
Por exemplo, considere uma collection inventory
com documentos que contêm um campo size
:
{ ..., size: { h: 10, w: 15.25, uom: "cm" }, ... }
A operação a seguir resultará em um erro Path collision
pois ela tenta projetar o documento size
e o campo size.uom
simultaneamente:
db.inventory.find( {}, { size: 1, "size.uom": 1 } )
Em versões anteriores, a projeção mais recente definida nos documentos incorporados e seus campos determinava a projeção:
Se a projeção do documento incorporado ocorrer após todas as projeções de seus campos, o MongoDB projetará o documento incorporado. Por exemplo, o documento de projeção
{ "size.uom": 1, size: 1 }
produz o mesmo resultado que o documento de projeção{ size: 1 }
.Se a projeção do documento incorporado ocorrer antes da projeção de qualquer um dos seus campos, o MongoDB projetará o campo ou campos especificados. Por exemplo, o documento de projeção
{ "size.uom": 1, size: 1, "size.h": 1 }
produz o mesmo resultado que o documento de projeção{ "size.uom": 1, "size.h": 1 }
.
Colisão de caminho: $slice
de uma array e campos incorporados
A busca e a projeção do findAndModify()
não podem conter um $slice
de uma array e um campo embutido na array.
Por exemplo, considere uma collection inventory
que contém um campo de array instock
:
{ ..., instock: [ { warehouse: "A", qty: 35 }, { warehouse: "B", qty: 15 }, { warehouse: "C", qty: 35 } ], ... }
A seguinte operação falha com um erro Path
collision
:
db.inventory.find( {}, { "instock": { $slice: 1 }, "instock.warehouse": 0 } )
Nas versões anteriores, a projeção aplica ambas as projeções e retorna o primeiro elemento ($slice: 1
) na array instock
, mas suprime o campo warehouse
no elemento projetado. A partir do MongoDB 4.4, para obter o mesmo resultado, use o método db.collection.aggregate()
com dois estágios $project
separados.
$
- Restrição de caminho do campo prefixado
A projeção e a projeção findAndModify()
não podem projetar um campo que começa com $
, com exceção dos campos DBRef.
Por exemplo, a seguinte operação é inválida:
db.inventory.find( {}, { "$instock.warehouse": 0, "$item": 0, "detail.$price": 1 } )
$
Restrição de colocação do operador posicional
O operador de projeção $
só pode aparecer no final do caminho do campo, por exemplo "field.$"
ou "fieldA.fieldB.$"
.
Por exemplo, a seguinte operação é inválida:
db.inventory.find( { }, { "instock.$.qty": 1 } )
Para resolver, remova o componente do caminho do campo que segue o operador de projeção $
.
$
Operador posicional e restrição $slice
O find e a projeção findAndModify()
não podem incluir a expressão de projeção $slice
como parte de uma expressão de projeção $
.
Por exemplo, a seguinte operação é inválida:
db.inventory.find( { "instock.qty": { $gt: 25 } }, { "instock.$": { $slice: 1 } } )
Nas versões anteriores, o MongoDB retorna o primeiro elemento (instock.$
) na anterior instock
que corresponde à condição de query, ou seja, a projeção posicional "instock.$"
tem precedência e a $slice:1
não contém nenhum oplog. "instock.$": {
$slice: 1 }
não exclui nenhum outro campo do documento.
Restrição de projeção de nome de campo vazio
a projeção e a projeção findAndModify()
não podem incluir uma projeção de um nome de campo vazio.
Por exemplo, a seguinte operação é inválida:
db.inventory.find( { }, { "": 0 } )
Nas versões anteriores, o MongoDB tratava a inclusão/exclusão do campo vazio como trataria a projeção de campos inexistentes.
Metadados de pesquisa de texto { $meta: "textScore" } requisito de query
A partir do MongoDB 4.4, você deve especificar o operador $text
no predicado de query das operações db.collection.find()
para usar a expressão { $meta: "textScore" }
na projeção ou classificação. Por exemplo:
db.articles.find( { $text: { $search: "cake" } }, { score: { $meta: "textScore" } } ); db.articles.find( { $text: { $search: "cake" } }, { score: { $meta: "textScore" } } ).sort( { score: { $meta: "textScore" } } );
Se você não especificar o operador $text
no predicado de query, a operação falhará. Por exemplo, as seguintes operações são inválidas começando no MongoDB 4.4:
db.articles.find( { }, { score: { $meta: "textScore" } } ) db.articles.find( { }, { score: { $meta: "textScore" } } ).sort( { score: { $meta: "textScore" } } );
$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.
Mapa Reduzir Alterações
Reduzir uma chave que contém um único valor
A partir do MongoDB 4.4, quando você executa o comando mapReduce
, o MongoDB chama a função reduce
independentemente de quantos valores estão contidos na chave associada.
Em versões anteriores, o MongoDB não chama a função reduce
para uma chave que tenha um único valor.
Para mais informações, consulte Uso.
Alteração da saída de redução de mapa
A partir do MongoDB 4.4, mapReduce
remove o campo counts
de sua saída.
Em versões anteriores, o comando inclui um campo counts
em sua saída. Por exemplo:
"counts" : { "input" : 4, "emit" : 4, "reduce" : 1, "output" : 2 },
Limite de emissão da função de mapa
A partir do MongoDB 4.4, a função map
não restringe mais o tamanho de cada saída de emit()
a metade do tamanho máximo do documento BSON do MongoDB.
Nas versões anteriores, uma única emissão só pode conter metade do tamanho máximo do documento BSONdo MongoDB
Remover compatibilidade com código JavaScript do tipo BSON com escopo
mapReduce
não é mais compatível com o código JavaScript do tipo BSON obsoleto com escopo (tipo BSON 15) para suas funções. As funções map
, reduce
e finalize
devem ser BSON tipo string (BSON tipo 2) ou BSON tipo JavaScript (BSON tipo 13). Para passar valores constantes que estarão acessíveis nas map
reduce
finalize
funções , e , use o scope
parâmetro .
O uso de código JavaScript com escopo para as funções mapReduce
foi descontinuado desde a versão 4.2.1.
Dica
Veja também:
Registro estruturado
A partir do MongoDB 4. As instâncias 4, mongod
/ mongos
agora geram todas as mensagens de registro no formato JSON estruturado. 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.
Se você tiver utilitários de análise de registro existentes ou usar um serviço de ingestão de registro, talvez seja necessário reconfigurar essas ferramentas para o novo formato de registro estruturado com o MongoDB 4.4.
Consulte Mensagens de registro para um exame detalhado do novo formato de registro estruturado, incluindo exemplos de análise de registro usando a nova estrutura de registro.
Remoção do valor rs
getLog
A partir do MongoDB 4.4, o comando getLog
não aceita mais o valor rs
, pois essa categorização do tipo de mensagem foi descontinuada. Em vez disso, as mensagens de registro agora são sempre identificadas por seu componente, incluindo REPL para mensagens de replicação.
Consulte Filtrando por componente para ver exemplos de análise de registros que filtram no campo de componente.
Formato de Registro de Data/Hora
Com a transição para o registro JSON estruturado, o formato de carimbo de data/hora do ctime
não é mais suportado. As seguintes opções de configuração não aceitam mais ctime
como um parâmetro válido:
Use os formatos de carimbo de data/hora iso8601-local
(padrão) ou iso8601-utc
.
Parâmetro maxLogSizeKB
Com a transição para o registro JSON estruturado, o parâmetro de servidor maxLogSizeKB
agora trunca quaisquer atributos individuais em uma entrada de registro que exceda o limite especificado. Anteriormente, esse parâmetro truncava toda a entrada de registro.
Além disso:
maxLogSizeKB
agora aceita um valor de0
, que desabilita totalmente a truncamento.maxLogSizeKB
não aceita mais valores negativos.
Consulte truncamento de mensagem de log para obter mais informações.
Alterações gerais
MongoDB 4.4 remove o suporte para o analisador gperftools cpu. Como parte dessa alteração, o
hostManager
não fornece mais a ação de privilégiocpuProfiler
no cluster.O parâmetro
ldapConnectionPoolMaximumConnectionsPerHost
agora tem um valor padrão de2
. Nas versões anteriores, o padrão não estava definido.serverStatus
retornaflowControl.locksPerKiloOp
em vez deflowControl.locksPerOp
.O operador de expressão
$dateFromParts
agora suporta um intervalo de valor de1-9999
para os camposyear
eisoWeekYear
. Em versões anteriores, o intervalo de valores suportado para estes campos era0-9999
.O método auxiliar de shell
listIndexes
emongo
db.collection.getIndexes()
não retorna mais o campons
do namespace nos documentos de especificação do índice.MongoDB 4.4 remove a opção de linha de comando
--noIndexBuildRetry
e a opçãostorage.indexBuildRetry
correspondente.mongos
agora registra um erro se você passar um valorwriteConcern
vazio, ou seja,writeConcern: {}
para um comando que não suporta write concern. Nas versões anteriores,mongos
ignora um valorwriteConcern
vazio para esses comandos.A opção
force
com o comandocompact
não é mais booleana.force: true
eforce: false
estão obsoletos e resultarão em um erro.
db.collection.validate() Parameter change
O mongo
método não aceita mais apenas um parâmetro db.collection.validate()
booleano.
Ou seja, o método não aceita mais db.collection.validate(<boolean>)
como uma abreviação para db.collection.validate({full: <boolean>})
:
Em vez de | Usar |
---|---|
db.collection.validate(true) | db.collection.validate({ full: true }) |
db.collection.validate(false) | db.collection.validate() -ou-db.collection.validate({ full: false }) |
Validação completa em oplog
A partir do MongoDB 4.4, a validação completa no oplog
para WiredTiger ignora a verificação mais completa. O validate.warnings
inclui um aviso do comportamento.
Limpeza do MMAPv1
O comando
dbStats
não retorna mais o campo MMAPv1numExtents
obsoleto.O comando
replSetGetStatus
não retorna mais o campo1replSetGetStatus.initialSyncStatus.fetchedMissingDocs
em sua saída.O comando
fsync
não aceita mais o campo1async
como uma opção.
Itens obsoletos
Geoespacial
MongoDB 4.4 substitui o índice geoHaystack e o comando geoSearch
. Em vez disso , use um índice d2 com $geoNear
ou $geoWithin
.
Tipo BSON Código JavaScript com escopo
Começando no MongoDB 4.4:
$where
não é mais compatível com o código JavaScript dos tipos de BSON obsoleto com escopo (tipo de BSON 15). O operador$where
suporta apenas a string dos tipos de BSON (tipo de BSON 2) ou JavaScript dos tipos de BSON (tipo de BSON 13).mapReduce
não é mais compatível com o código JavaScript do tipo BSON obsoleto com escopo (tipo BSON 15) para suas funções. As funçõesmap
,reduce
efinalize
devem ser BSON tipo string (BSON tipo 2) ou BSON tipo JavaScript (BSON tipo 13). Para passar valores constantes que estarão acessíveis nasmap
reduce
finalize
funções , e , use oscope
parâmetro .O uso de código JavaScript com escopo para as funções
mapReduce
foi descontinuado desde a versão 4.2.1.
O uso do código JavaScript do tipo BSON com escopo para $where
e as funções mapReduce
foi descontinuado desde o MongoDB 4.2.1.
Fragmentação
MongoDB 4.4 descontinua os seguintes comandos de fragmentação:
shardConnPoolStats
(useconnPoolStats
em vez disso)
Limite de tamanho do arquivo de estouro da tabela Lookaside
O arquivo de estouro de cache da tabela de lookaside do WiredTiger (LAS) não existe mais a partir do MongoDB 4.4. Como tal, MongoDB 4.4 descontinua as seguintes opções e parâmetros para o limite de arquivo de estouro de cache (LAS); estas opções e parâmetros não têm efeito a partir do MongoDB 4.4:
storage.wiredTiger.engineConfig.maxCacheOverflowFileSizeGB
opção de arquivo de configuração--wiredTigerMaxCacheOverflowFileSizeGB
opção de linha de comandowiredTigerMaxCacheOverflowSizeGB
Parâmetro
4.4 Compatibilidade de recursos
Alguns recursos do 4.4 exigem não apenas o 4.4 binários, mas o featureCompatibilityVersion (FCV) definido como 4.4. Esses recursos incluem:
Aumenta o limite de comprimento do namespace para versões do MongoDB com fCV definido como 4.4+.
A criação de índices compostos com hash requer fCV definido como 4.4+.