Alterações de compatibilidade no MongoDB 8.0

Queries para nulo não correspondem a campos indefinidos

A partir do MongoDB 8.0, as comparações com null em expressões de correspondência de igualdade não correspondem aos valores undefined .

Por exemplo, considere estes documentos e consulte:

// people collection
[
   { _id: 1, name: null },
   { _id: 2, name: undefined },
   { _id: 3, name: [ "Gabriel", undefined ],
   { _id: 4, names: [ "Alice", "Charu" ] }
]

db.people.find( { name: null } )

Antes do MongoDB 8.0, a query anterior corresponderia a documentos onde:

• O campo name é null (_id: 1)

• O campo name é undefined ou contém um elemento de array undefined (_id: 2 e _id: 3)

• O campo name não existe (_id: 4)

A partir do MongoDB 8.0, a query anterior não corresponde a documentos em que o campo name seja undefined ou contenha undefined elementos de array. A query corresponde apenas a documentos onde:

• O campo name é null ou contém um elemento de array null (_id: 1)

• O campo name não existe (_id: 4)

Essa mudança de comportamento da query também afeta as operações:

• $eq

• $in

• $lookup, porque um campo local null não corresponde mais a um campo externo undefined .

Para saber como reescrever suas queries ou migrar seus dados para levar em conta essa mudança de comportamento, consulte Migrar Dados e Queries Indefinidos.

Não é possível se conectar diretamente ao shard e executar comandos

A partir do MongoDB 8.0, você só pode executar determinados comandos em shards. Se você tentar se conectar diretamente a um fragmento e executar um comando não suportado, o MongoDB retornará um erro:

"You are connecting to a sharded cluster improperly by connecting directly
to a shard. Please connect to the cluster via a router (mongos)."

Para executar um comando de banco de dados de dados não suportado diretamente em um shard, você deve se conectar a mongos ou ter a função directShardOperations somente de manutenção.

O MongoDB oferece suporte à transição online de um conjunto de réplicas para um cluster 1-shard, permitindo que os comandos sejam executados diretamente em um shard. No entanto, quando o cluster tiver mais de um shard, somente os comandos listados poderão ser executados diretamente no shard sem a função directShardOperations somente de manutenção.

Maioria das preocupações com gravação

A partir do MongoDB 8.0, as operações de gravação que usam a preocupação de gravação "majority" retornam uma confirmação quando a maioria dos membros do conjunto de réplicas tiver escrito a entrada de oplog para a alteração. Isso melhora o desempenho de "majority" gravações. Em versões anteriores, essas operações aguardavam e retornavam uma confirmação após a maioria dos membros do conjunto de réplicas aplicar a alteração.

Buffers de oplog

A partir do MongoDB 8.0, os secundários gravam e aplicam entradas de oplog para cada lote em paralelo. Isso introduz uma alteração interruptiva para a métrica de status do metrics.repl.buffer , pois agora fornece informações em dois buffers em vez de um.

O MongoDB 8.0 descontinua as seguintes métricas de status do servidor :

• metrics.repl.buffer.count

• metrics.repl.buffer.maxSizeBytes

• metrics.repl.buffer.sizeBytes

Ele os substitui por estas métricas:

• metrics.repl.buffer.apply.count

• metrics.repl.buffer.apply.maxSizeBytes

• metrics.repl.buffer.apply.sizeBytes

• metrics.repl.buffer.write.count

• metrics.repl.buffer.write.maxSizeBytes

• metrics.repl.buffer.write.sizeBytes

Desempenho do desligamento

A partir do MongoDB 8.0, Bulk.insert() e cargas de trabalho de ingestão de dados podem ter um desempenho melhor. No entanto, desligar o MongoDB imediatamente após a execução dessas cargas de trabalho pode levar mais tempo devido aos dados extras que estão sendo liberados para o disco.

Comandos compactos simultâneos não permitidos

A partir do MongoDB 8.0, se você tentar executar vários comandos compact simultâneos na mesma coleção, o MongoDB retornará um erro.

Validação de entrada geoespacial

A partir do MongoDB 8.0, você não pode usar queries geoespaciais com entrada malformada. Em versões anteriores, determinadas queries geoespaciais aceitam entrada malformada sem erro.

Os provedores de identidade da OIDC podem compartilhar um emissor

A partir do MongoDB 8.0, quando vários fornecedores de identidade (IDP) são definidos, o parâmetro oidcIdentityProviders aceita valores issuer duplicados, desde que o valor audience seja exclusivo para cada emissor. Isso também está disponível nas versões 7.3 e 7.0.

Alteração de saída doserverStatus

A partir do MongoDB 8.0, wiredTiger.concurrentTransactions foi renomeado para queues.execution.

Coleções system.buckets de séries temporais

Todas as system.buckets coleções do devem ter opções de série temporal válidas configuradas antes de atualizar para MongoDB 8.0. Se você tiver uma system.buckets coleção que não seja uma coleção de séries temporais, não poderá atualizar para o MongoDB 8.0.

$rank e $denseRank comportamento

A partir do MongoDB 8.0, null e valores de campo ausentes nas operações $denseRank e $rank sortBy são tratados da mesma forma ao calcular classificações. Essa alteração torna o comportamento de denseRank e rank consistente com $sort.

Saída $shardedDataDistribution

A partir do MongoDB 8.0, $shardedDataDistribution só retorna a saída para o primary shard de uma collection se o primary shard tiver chunks ou documentos órfãos.

Para detalhes, consulte $shardedDataDistribution.

TCMalloc atualizado

A partir do MongoDB 8.0, O MongoDB usa uma versão atualizada do TCMalloc que usa caches por CPU, em vez de caches por thread, para reduzir a fragmentação da memória e tornar seu banco de dados de dados mais resiliente a cargas de trabalho de alto estresse.

Para usar o novo TCMalloc com melhor desempenho, consulte Otimização de desempenho do TCMalloc para uma implantação autogerenciada.