:Alterações de compatibilidade no MongoDB 4.2

Opções específicas do MMAPv1

O MongoDB 4.2 remove as seguintes opções específicas do MMAPv1:

Parâmetros específicos do MMAPv1

O MongoDB 4.2 remove os seguintes parâmetros específicos do MMAPv1:

• newCollectionsUsePowerOf2Sizes

• replIndexPrefetch

Comando específico do MMAPv1

O MongoDB 4.2 remove o comando touch, que era específico do MMAPv1.

Opções específicas do MMAPv1 para comandos e métodos

As seguintes opções específicas do MMAPv1 foram removidas no MongoDB 4.2:

• noPadding e usePowerOf2Sizes do comando collMod.

• verbose do comando collStats.

• flags do comando create.

• paddingFactor, paddingBytes e preservePadding do comando db.createCollection().

O MongoDB 4.2 ignora a opção async, específica do MMAPv1, no comando fsync.

Descontinuação do comando group

A partir do MongoDB 4.2, o comando group (descontinuado no MongoDB 3.4) e sua função auxiliar do mongo shell db.collection.group() tornaram-se obsoletos.

Utilize db.collection.aggregate() juntamente com o estágio $group como alternativa.

Descontinuação do comando eval

O comando eval foi descontinuado a partir do MongoDB 4.2 (originalmente descontinuado no MongoDB 3.0).

As funções auxiliares do mongo shell db.eval() e db.collection.copyTo() só podem ser executadas quando conectadas a uma instância rodando o MongoDB 4.0 ou versões anteriores.

Descontinuação dos comandos copydb e clone

Os comandos copydb e clone tornaram-se obsoletos a partir do MongoDB 4.2. As funções auxiliares do mongo shell db.copyDatabase() e db.cloneDatabase() só funcionam em conexões com instâncias do MongoDB 4.0 ou anteriores.

Como alternativa, utilize o mongodump e o mongorestore (com as opções --nsFrom e --nsTo do mongorestore) ou um driver para criar um script.

mongodump --archive --db=test | mongorestore --archive  --nsFrom='test.*' --nsTo='examples.*'

Descontinuação do comando parallelCollectionScan

O comando parallelCollectionScan foi descontinuado a partir do MongoDB 4.2.

Remoção da opção maxScan

A opção maxScan foi removida do comando find e da função auxiliar do mongo shell cursor.maxScan() no MongoDB 4.2. Utilize a opção maxTimeMS do comando find ou o método cursor.maxTimeMS() do mongo shell como substituto.

Descontinuação do comando geoNear

O comando geoNear tornou-se obsoleto a partir do MongoDB 4.2. Use o estágio de agregação $geoNear em seu lugar.

As opções do estágio $geoNear são semelhantes às do comando descontinuado geoNear, com as seguintes exceções:

• A saída do comando descontinuado geoNear incluía o campo dis com informações de distância.

  No estágio $geoNear, especifique o nome do campo de distância em distanceField.

• O comando descontinuado geoNear aceitava um valor booleano na opção includeLocs para incluir o campo loc.

  No estágio $geoNear, especifique o nome do campo de localização em includeLocs.

• A saída do comando descontinuado geoNear incluía avgDistance e maxDistance.

  É possível obter avgDistance e maxDistance usando o pipeline de agregação. Especificamente, inclua o estágio group após o estágio geoNear para calcular esses valores.

  db.places.aggregate([
     { $geoNear: { near: <...>, distanceField: "dis", includeLocs: "loc", spherical: true, ... } },
     { $group: { _id: null, objectsLoaded: { $sum: 1 }, maxDistance:
           { $max: "$dis" }, avgDistance: { $avg: "$dis" } } }
  
  ])

Descontinuação do comando repairDatabase

A partir do MongoDB 4.2, o comando repairDatabase, a função auxiliar do mongo shell db.repairDatabase() e a permissão repairDatabase tornaram-se obsoletos.

Alternativas disponíveis:

• Para compactar dados em um mongod, utilize o comando compact.

• Para reconstruir índices em uma instância standalone, execute o comando reIndex ou sua função auxiliar db.collection.reIndex().

• Para reparar dados de uma instância standalone, use mongod --repair.

Descontinuação do comando getPrevError

O comando getPrevError e sua função auxiliar do mongo shell db.getPrevError() foram descontinuados a partir do MongoDB 4.2.

Descontinuação do comando cloneCollection

O comando cloneCollection e sua função auxiliar do mongo shell db.cloneCollection() tornaram-se obsoletos a partir do MongoDB 4.2.

Utilize os comandos mongoexport e mongoimport ou um driver para escrever um script como alternativa.

Descontinuação dos comandos PlanCache

Os seguintes itens foram descontinuados a partir do MongoDB 4.2:

• O método PlanCache.getPlansByQuery() e o comando planCacheListPlans.

  Para obter os planos de consulta em cache para um formato (shape), utilize o estágio de agregação $planCacheStats.

• O método PlanCache.listQueryShapes() e o comando planCacheListQueryShapes.

  Para listar os formatos de consulta em cache, utilize o estágio de agregação $planCacheStats.

Limites do estágio $out

Remoção das opções limit e num do $geoNear

O MongoDB 4.2 removeu as opções limit e num do $geoNear, bem como o limite padrão de 100 documentos. Para limitar os resultados do $geoNear, combine o estágio $geoNear com o estágio $limit.

Por exemplo, a agregação abaixo, onde o estágio $geoNear inclui a opção num, não é mais válida no MongoDB 4.2.

db.places.aggregate([
   {
     $geoNear: {
        near: { type: "Point", coordinates: [ -73.99279 , 40.719296 ] },
        distanceField: "distance",
        num: 5,                 // Not supported in 4.2
        spherical: true
     }
   }
])

Reescreva o comando de agregação no seguinte formato:

db.places.aggregate([
   {
     $geoNear: {
        near: { type: "Point", coordinates: [ -73.99279 , 40.719296 ] },
        distanceField: "distance",
        spherical: true
     }
   },
   { $limit: 5 }
])

Disponibilidade

A partir do MongoDB 4.2, os change streams estão disponíveis independentemente de o nível de read concern "majority" oferecer suporte a eles.

Antes do MongoDB 4.2, os change streams só estavam disponíveis se o suporte ao read concern "majority" estivesse ativado (configuração padrão).

Collation padrão

No MongoDB 4.2, os change streams usam comparações binárias simples, a menos que uma collation explícita seja fornecida. Em versões anteriores, os change streams criados para uma única coleção via db.collection.watch() herdavam a collation padrão da coleção.

Modificação do token de retomada

Se um pipeline de agregação de change stream modificar o campo _id de um evento a partir do MongoDB 4.2, uma exceção será lançada.

Modo FIPS

A opção --sslFIPSMode foi removida dos seguintes programas a partir do MongoDB 4.2:

• mongodump

• mongoexport

• mongofiles

• mongoimport

• mongorestore

• mongostat

• mongotop

Esses programas utilizam conexões compatíveis com FIPS automaticamente quando o modo FIPS está habilitado nas instâncias mongod e mongos.

Extended JSON v2

**Opção --query**

A partir do MongoDB 4.2, a opção --query para mongodump e mongoexport deve estar no formato Extended JSON v2 (Modo Relaxado ou Estrito), incluindo nomes de campos e operadores entre aspas. Exemplo:

mongoexport -d=test -c=records -q='{ "a": { "$gte": 3 }, "date": { "$lt": { "$date": "2016-01-01T00:00:00.000Z" } } }' --out=exportdir/myRecords.json

Antes do MongoDB 4.2, a opção --query usava o formato Extended JSON v1, onde nomes de campos e operadores não precisavam estar entre aspas.

mongoexport -d=test -c=records -q='{ a: { $gte: 3 }, date: { $lt: { "$date": "2016-01-01T00:00:00.000Z" } } }' --out=exportdir/myRecords.json

Step down do primário

A partir do MongoDB 4.2, o comando replSetStepDown (ou replSetReconfig que cause um step down) não fecha mais todas as conexões de clientes. Contudo, operações de escrita ainda em andamento são encerradas.

Antes do MongoDB 4.0, o replSetStepDown fechava todas as conexões de clientes durante o step down.

Estado ROLLBACK

Quando um membro entra no estado ROLLBACK a partir do MongoDB 4.2, todas as operações de usuário são encerradas.

Índices

{
   "ok" : 0,
   "errmsg" : "Index with name: x_1 already exists with a different name",
   "code" : 85,
   "codeName" : "IndexOptionsConflict"
}

{
   "numIndexesBefore" : 2,
   "numIndexesAfter" : 2,
   "note" : "all indexes already exist",
   "ok" : 1
}

min()/max()

Ao especificar min()/max() em uma operação db.collection.find() a partir do MongoDB 4.2, é obrigatório especificar explicitamente um índice para min()/max(), exceto se a consulta find() for uma condição de igualdade no campo _id { _id: }.

Da mesma forma, ao especificar min/max no comando find, você deve fornecer explicitamente o hint para o índice min/max.

Antes do MongoDB 4.0, a especificação explícita do índice min()/max() era opcional. Sem um hint explícito nessas versões, o MongoDB selecionava um índice com base nos limites do índice. Porém, se múltiplos índices existissem nos mesmos campos com ordens de classificação diferentes, a seleção poderia ser ambígua.

CurrentOp

Ao relatar operações "getmore", o estágio de agregação $currentOp, o comando currentOp e db.currentOp() agora retornam o campo originatingCommand como um campo aninhado do novo campo cursor. Antes do MongoDB 4.2, originatingCommand era um campo de nível superior no documento "getmore".

Status do servidor

As métricas opcounters e opcountersRepl retornadas por serverStatus e db.serverStatus agora são inteiros de 64 bits (NumberLong) em vez de inteiros de 32 bits (NumberInt).

Logging

• Ao registrar logs no syslog, o formato do texto da mensagem agora inclui informações do componente. Exemplo:

  ...  ACCESS   [repl writer worker 5] Unsupported modification to roles collection ...

  Em versões anteriores ao MongoDB 4.2, as mensagens do syslog não incluíam essas informações. Exemplo:

  ... [repl writer worker 1] Unsupported modification to roles collection ...

• Comandos de recuperação de log no MongoDB 4.2 truncam eventos com mais de 1.024 caracteres. Em versões anteriores, o truncamento ocorria após 512 caracteres.

• O MongoDB 4.2 registra o nível de log de depuração específico. Por exemplo, se o nível for 2, ele registra D2.

  Antes dessa versão, as mensagens de log especificavam apenas D como nível de depuração.

Protocolo wire

O MongoDB 4.2 deixou de suportar OP_COMMAND e o protocolo de escrita correspondente OP_COMMANDREPLY.

Alterações em Killcursors

Remoção do parâmetro AsyncRequestsSenderUseBaton

O parâmetro AsyncRequestsSenderUseBaton foi removido no MongoDB 4.2, e a melhoria de desempenho controlada por ele agora está sempre ativa.

Validação mais rigorosa da sintaxe de count

O MongoDB 4.2 implementa validação mais rigorosa para nomes de opções no comando count. Se um nome de opção desconhecido for especificado, o comando retornará erro.

Versões anteriores ignoravam nomes de opções inválidos.

Sessões causalmente consistentes

Os seguintes comandos deixaram de suportar afterClusterTime a partir do MongoDB 4.2:

• Comando dbHash

• Comando mapReduce

• Comando validate

Consequentemente, essas operações não podem ser associadas a sessões causalmente consistentes.

Remoção da métrica fastmodinsert

A métrica descontinuada fastmodinsert foi removida de várias saídas no MongoDB 4.2, incluindo o executionStats do explain e a saída do profiler.

Map-Reduce

Os seguintes itens tornaram-se obsoletos a partir do MongoDB 4.2:

• A opção map-reduce para criar uma coleção sharded e o suporte ao uso da opção sharded para map-reduce. Para gerar saída em uma coleção sharded, crie-a previamente. A substituição de uma coleção sharded existente também foi descontinuada.

• Especificação explícita da opção nonAtomic: false para map-reduce.

Status do balancer e auto splitting

Mudanças no MongoDB 4.2:

• O comando balancerStart e os métodos auxiliares do mongo shell sh.startBalancer() e sh.setBalancerState(true) também ativam o auto splitting.

  Para desativar o auto splitting, utilize sh.disableAutoSplit().

• O comando balancerStop e os métodos auxiliares sh.stopBalancer() e sh.setBalancerState(false) também desativam o auto splitting.

  Para ativar o auto splitting, utilize sh.enableAutoSplit().

Os métodos sh.enableBalancing(namespace) e sh.disableBalancing(namespace) não afetam mais o auto splitting.

Relatórios de diagnóstico de locks

O MongoDB 4.2 passou a relatar informações sobre o lock ReplicationStateTransition.

Além disso, as informações de lock do ParallelBatchWriterMode agora são separadas das informações de lock global. Versões anteriores relatavam o ParallelBatchWriterMode como parte do lock global.

Para operações que relatam informações de lock, consulte:

• O comando serverStatus e o método db.serverStatus().

• O estágio de pipeline de agregação $currentOp, o comando currentOp e o método db.currentOp().

Validação de argumentos de consulta, ordenação ou projeção para findAndModify

A partir do MongoDB 4.2 (incluindo V4.0.12+ e 3.6.14+), o comando findAndModify e seus métodos associados do mongo shell retornam erro quando o argumento de consulta, ordenação ou projeção especificado não é um documento.

Antes do MongoDB 4.2, a operação considerava argumentos de consulta ou ordenação não documentais como um documento vazio {}.

DropDatabase e movePrimary

Novos requisitos a partir do MongoDB 4.2:

• Se você excluir um banco de dados e criar outro com o mesmo nome, execute uma das seguintes operações:

  • Reinicie todas as instâncias mongos e membros do shard, ou

  • Execute o comando flushRouterConfig em todas as instâncias mongos e membros do shard antes de ler ou gravar no banco criado.

• Se utilizar o comando movePrimary para mover coleções não sharded, execute uma das seguintes operações:

  • Reinicie todas as instâncias mongos e membros do shard, ou

  • Execute o comando flushRouterConfig em todas as instâncias mongos e membros do shard antes de ler ou gravar nessas coleções.

Isso garante que o mongos e os membros do shard limpem seus caches de metadados. Caso contrário, leituras podem perder dados e gravações podem ser direcionadas ao shard incorreto, exigindo intervenção manual para correção.

Antes do MongoDB 4.2, bastava reiniciar as instâncias mongos ou executar o comando flushRouterConfig apenas nelas.

Remoção das coleções system.indexes e system.namespaces

As coleções system.indexes e system.namespaces (descontinuadas no MongoDB 3.0) foram removidas no MongoDB 4.2.

Com essa remoção, as funções integradas clusterManager, clusterMonitor, dbAdmin, read, restore e outras funções que herdam delas não possuem mais permissões para acessar as coleções system.indexes e system.namespaces.

Necessidade de limpar diretórios de dados ao fazer downgrade de arbiter

Os arquivos de dados do arbiter no MongoDB 4.2 são incompatíveis com o MongoDB 4.0. Para fazer downgrade de 4.2 para 4.0, exclua primeiro os arquivos de dados do arbiter. O uso de arquivos de dados do 4.2 para executar um arbiter no 4.0 pode causar erros.

Coleções sharded e substituição de documentos

Comportamentos alterados no MongoDB 4.2:

• Uma operação de substituição de documento, como replaceOne() ou update() (quando usada com documento de substituição), tenta primeiro localizar um shard usando o filtro de consulta. Se falhar, tenta utilizar o documento de substituição. Antes do 4.2, a tentativa era feita apenas com o documento de substituição.

• O método save() foi descontinuado. Utilize insertOne() ou replaceOne(). O método save() não funciona em coleções sharded cuja chave de shard não seja _id, resultando em erro.

• Para operações de substituição com upsert: true em coleções sharded, o filtro deve incluir uma correspondência exata na chave de shard da coleção.