Alterações de compatibilidade no MongoDB 5.0

As seguintes alterações do 5.0 podem afetar a compatibilidade com versões mais antigas do MongoDB.

Certos comandos aceitam somente parâmetros reconhecidos

A partir do MongoDB 5.0, determinados comandos de banco de dados geram um erro se for passado um parâmetro não explicitamente aceito pelo comando. No MongoDB 4.4 e versões anteriores, os parâmetros não reconhecidos são silenciosamente ignorados.

Comandos afetados:

Comandos removidos

A partir do MongoDB 5.0, estes comandos do banco de dados e métodos de assistente de shell mongo foram removidos:

Comando removido	Alternativa
`db.collection.copyTo()`	`$out`
`db.collection.ensureIndex()`	`db.collection.createIndex()`
`db.collection.save()`	`db.collection.insertOne()` `db.collection.insertMany()`
`db.resetError()`	Não disponível
`geoSearch`	Um dos Operadores de Consulta Geoespacial
`Mongo.getSecondaryOk()`	Mongo.getReadPrefMode()
`Mongo.isCausalConsistency`	Não disponível
`Mongo.setSecondaryOk()`	Mongo.setReadPref()
`rs.secondaryOk()`	Mongo.setReadPref()
`resetError`	Não disponível
`shardConnPoolStats`	`connPoolStats`
`unsetSharding`	Não disponível

Parâmetros removidos

O MongoDB 5.0 remove os seguintes parâmetros do servidor:

Parâmetros removidos	Descrição
`cachePressureThreshold`	O MongoDB 5.0 remove o parâmetro de servidor do `cachePressureThreshold`. Devido a alterações na forma como o WiredTiger calcula o tamanho da janela de captura instantânea, este parâmetro não é mais relevante.
`shouldMultiDocTxnCreateCollectionAndIndexes`	O MongoDB 5.0 remove o parâmetro de servidor `shouldMultiDocTxnCreateCollectionAndIndexes` . A partir do 5.0, a criação de collections e índices dentro das transações está sempre habilitada. Você não pode mais usar o parâmetro server para desabilitar esse comportamento.
`connPoolMaxShardedConnsPerHost`	O MongoDB 5.0 remove o parâmetro de servidor do `connPoolMaxShardedConnsPerHost`.
`connPoolMaxShardedInUseConnsPerHost`	O MongoDB 5.0 remove o parâmetro de servidor do `connPoolMaxShardedInUseConnsPerHost`.
`shardedConnPoolIdleTimeoutMinutes`	O MongoDB 5.0 remove o parâmetro de servidor do `shardedConnPoolIdleTimeoutMinutes`.

Tipos de índice removidos

O MongoDB 5.0 remove o índice geoHaystack obsoleto. Em vez disso, use um índice 2D.

Atualizar sua instância MongoDB para 5.0 e configurar featureCompatibilityVersion para 5.0 excluirá quaisquer índices geoHaystack preexistentes.

Métricas removidas

A partir do MongoDB 5.0, o comando serverStatus não gera opReadConcernCounters, que contém o nível de read concern especificado pelas operações de query. Em vez disso, o novo readConcernCounters substitui opReadConcernCounters e contém informações adicionais.

Iniciando no MongoDB 5.0, o comando serverStatus não produz o cache pressure percentage threshold e o current cache pressure percentage em wiredTiger.snapshot-window-settings.

`currentOp` Alteração de saída

A partir do MongoDB 5.0, a métrica $currentOp.remainingOperationTimeEstimated só está presente no fragmento do destinatário quando uma operação de refragmentação está ocorrendo.

Suporte a pi de framboesa removido

O MongoDB 5.0 remove a compatibilidade com Raspberry Pi. Para executar o MongoDB no Raspberry Pi, instale a versão 4.4.

Comportamento do TTL quando definido como `expireAfterSeconds` `NaN`

A partir do MongoDB 5.0, os índices TTL com expireAfterSeconds definido como NaN sofrem uma alteração de comportamento em comparação com as versões anteriores.

A mudança de comportamento afeta:

atualizações diretas
sincronização inicial de versões anteriores
mongorestore de versões anteriores

Executar qualquer uma dessas ações faz com que um valor de expireAfterSeconds de NaN seja tratado como um expireAfterSeconds de 0. Como resultado, os documentos podem expirar imediatamente.

Iniciando no MongoDB 5.0.14 (e 6.0.2), o servidor não utilizará índices TTL que tenham expireAfterSeconds definido como NaN.

Mudanças no shell

O shell mongo foi descontinuado no MongoDB v5.0. O shell substituto é mongosh.

O empacotamento do shell também muda no MongoDB v5.0. Consulte as instruções de instalação para ver mais detalhes.

Conjuntos de réplicas

`enableMajorityReadConcern` Não é configurável

A partir do MongoDB 5.0, enableMajorityReadConcern e --enableMajorityReadConcern não podem ser alterados e são sempre definidos como true devido a melhorias no mecanismo de armazenamento.

Em versões anteriores do MongoDB, enableMajorityReadConcern e --enableMajorityReadConcern são configuráveis e podem ser configurados como false para evitar que a pressão do cache de armazenamento imobilize um sistema com uma arquitetura PSA (primary-secondary-arbiter) de três membros.

Se você estiver usando uma arquitetura PSA (primária-secundária-arbiter) de três membros, considere o seguinte:

A preocupação de gravação "majority" pode causar problemas de desempenho se um secundário não estiver disponível ou estiver atrasado. Para obter conselhos sobre como mitigar esses problemas, consulte Atenuar problemas de desempenho com um conjunto de réplicas de PSA autogerenciado.
Se você estiver usando um "majority" padrão global e o write concern for menor do que o tamanho da maioria, suas consultas poderão retornar dados obsoletos (não totalmente replicados).

`secondaryDelaySecs` Definição de configuração

A partir de MongoDB 5.0, secondaryDelaySecs substitui slaveDelay. Esta alteração não é compatível com versões anteriores.

Nomes de host necessários para DNS do Split Horizon

Para configurar nós de cluster para DNS de horizonte dividido, use nomes de host em vez de endereços IP.

Começando no MongoDB v5,0, replSetInitiate e replSetReconfig rejeitam configurações que usam endereços IP em vez de nomes de host.

Use disableSplitHorizonIPCheck para modificar nós que não podem ser atualizados para usar nomes de host. O parâmetro se aplica somente aos comandos de configuração.

mongod e mongos não dependem de disableSplitHorizonIPCheck para validação na inicialização. As instâncias legadas de mongod e mongos que usam endereços IP em vez de nomes de host podem ser iniciadas após a atualização.

As instâncias configuradas com endereços IP registram um aviso para usar nomes de host em vez de endereços IP.

Leituras não transacionais em `config.transactions`

A partir do MongoDB 5.0, as leituras sem transação não são permitidas na collection config.transactions com os seguintes read concerns e opções:

"snapshot"
"majority" e a opção afterClusterTime está definida
Ao usar um driver do MongoDB e "majority" em uma sessão causalmente consistente

Escritas manuais do Oplog

A partir do MongoDB 5.0, não é mais possível realizar operações manuais de gravação no oplog em um cluster executado como um conjunto de réplicas.A execução de operações de gravação no oplog executado como uma instância standalone só deve ser feita com a orientação do Suporte do MongoDB.

Reconfiguração automática para novos membros do conjunto de réplicas de votação

A partir do MongoDB 5.0, um secundário recém-adicionado não conta como um membro votante e não pode ser eleito até que tenha atingido o estado SECONDARY.

Quando um novo nó de votação é adicionado a um conjunto de réplicas, replSetReconfig adicionará internamente um campo newlyAdded à configuração do nó. Os nós com o campo newlyAdded não contam para o número atual de nós de votação. Quando a sincronização inicial for concluída e o nó atingir o estado SECONDARY, o campo newlyAdded será automaticamente removido.

Observação

As configurações que tentam adicionar um campo chamado newlyAdded apresentarão erros mesmo se executadas com { force: true }.
Se um nó existente tiver um campo newlyAdded, utilizar rs.reconfig() para alterar a configuração não removerá o campo newlyAdded. O campo newlyAdded será anexado à configuração fornecida pelo usuário.
replSetGetConfig removerá todos os campos newlyAdded de saída. Se quiser ver quaisquer campos newlyAdded, você pode fazer a query da collection local.system.replset diretamente.

Valores personalizáveis removidos para getLastErrorDefaults

A partir do MongoDB 5.0, você não pode especificar uma preocupação de gravação padrão com settings.getLastErrorDefaults diferente do padrão { w: 1, wtimeout: 0 } . 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.

Confirmação de gravação do conjunto de réplicas

Iniciando no MongoDB 5.0, os membros do conjunto de réplicas no estado STARTUP2 não participam em majorias de escrita.

Dica

Veja também:

Write concern para conjuntos de réplicas

Write concern padrão implícito

A partir do MongoDB 5.0, o write concern padrão implícito é w: majority. No entanto, considerações especiais são feitas para sistemas contendo arbiters:

A maioria dos votos de um conjunto de réplicas é de 1 mais metade do número de membros votantes, arredondado para baixo. Se o número de membros votantes portadores de dados não for maior que a maioria votante, o write concern padrão é { w: 1 }.
Em todos os outros cenários, a preocupação de gravação padrão é { w: "majority" }.

Especificamente, MongoDB usa a seguinte fórmula para determinar a preocupação de escrita padrão:

if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ]
    defaultWriteConcern = { w: 1 }
else
    defaultWriteConcern = { w: "majority" }

Por exemplo, considere as seguintes implantações e suas respectivas preocupações de escrita padrão:

Non-Arbiters	Árbitros	Nós de votação	Maioria dos nós de votação	Write concern padrão implícito
2	1	3	2	`{ w: 1 }`
4	1	5	3	`{ w: "majority" }`

No primeiro exemplo:
- Existem 2 não-arbitores e 1 árbitro para um total de 3 nós de votação.
- A maioria dos nós de votação (1 mais metade de 3, arredondado para baixo) é 2.
- O número de não-arbitros (2) é igual à maioria dos nós de votação (2), resultando em uma preocupação implícita de escrita de { w: 1 }.
No segundo exemplo:
- Existem 4 não-árbitros e 1 árbitro para um total de 5 nós votantes.
- A maioria dos nós de votação (1 mais metade de 5, arredondado para baixo) é 3.
- O número de não-arbitros (4) é maior que a maioria dos nós de votação (3), resultando em uma preocupação implícita de escrita de { w: "majority" }.

O write concern padrão { w: "majority" } oferece uma garantia de durabilidade mais forte no caso de uma eleição ou se os membros do conjunto de réplicas ficarem indisponíveis.

Preocupação de leitura `snapshot` em coleções limitadas

A partir do MongoDB 5.0, você não pode utilizar a read concern "snapshot" ao ler de uma capped collection.

`local` é a preocupação de leitura padrão

A partir do MongoDB 5.0, "local" é o read concern padrão para operações de leitura contra o primary e o secundário.

Isso pode introduzir um aumento significativo de latência para queries de contagem que usam um filtro e para queries cobertas.

Você pode desativar esse comportamento definindo a preocupação de leitura em todo o cluster com setDefaultRWConcern.

Novo tipo de retorno `cursor.map()`

cursor.map() retornou um Array no shell mongo herdado. O tipo de retorno é Cursor em mongosh. Você pode usar .toArray() para converter os resultados.

Atualizar alterações do operador

A partir do MongoDB 5.0, mongod não gera mais um erro quando você usa os seguintes operadores de atualização com uma expressão de operando vazia ( { } ):

Uma atualização vazia não resulta em alteração e nenhuma entrada no oplog é criada (o que significa que a operação é um no-op).

Atualizar ordem de processamento do operador

A partir do MongoDB 5.0, os operadores de atualização processam campos de documento com nomes baseados em cadeia de caracteres em ordem lexicográfica. Os campos com nomes numéricos são processados em ordem numérica. Consulte Atualizar Comportamento de Operadores para detalhes.

`$setWindowFields` Estágio com transações e read concern de snapshots

Nas versões do MongoDB anteriores à 5.3, o estágio do pipeline de agregação $setWindowFields não pode ser usado com transações ou com a preocupação de leitura "snapshot".

Limites do parâmetro do operador do aggregation pipeline

Os seguintes operadores de pipeline de agregação agora têm um limite máximo de valor inteiro de bits.

Se você passar um valor que excede esse limite, o pipeline retornará um erro de argumento inválido.

`listDatabases` Alterações de saída

A partir do MongoDB 5.0, a saída do comando listDatabases em execução em um mongod é mais consistente com a saída de listDatabases em execução em um mongos.

A tabela seguinte mostra as diferenças em tipos de dados para campos de saída do listDatabases entre MongoDB 5.0 e versões anteriores. Somente os campos que diferem entre versões 5.0 e anteriores são listados.

Campo	Digite MongoDB 5.0	Digite MongoDB 4.4 e anterior (`mongod`)	Digite MongoDB 4.4 e anterior (`mongos`)
`sizeOnDisk`	inteiro	double	inteiro
`totalSize`	inteiro	double	inteiro
`totalSizeMb`	inteiro	não presente (veja abaixo)	inteiro

A saída de listDatabases agora inclui o campo totalSizeMb quando executada com mongos ou mongod. No MongoDB 4.4 e anterior, o totalSizeMb somente aparece ao executar contra mongos. totalSizeMb é a soma dos campos sizeOnDisk, expressos em megabytes.

Quando executado em mongos, o campo shards na saída dolistDatabases contém um par campo-valor para cada coleção em um fragmento específico. Os valores de tamanho no campo shards são expressos como inteiros.

Segurança

Aviso de inicialização do certificado de conexão TLS X509

A partir do MongoDB 5.0, mongod e mongos agora emitem um aviso de inicialização quando seus certificados não incluem um atributo Subject Alternative Name.

As seguintes plataformas não suportam validação de nome comum:

iOS 13 e superior
MacOS 10.15 e superior
Vá para 1,15 e superior

Os clientes que usam essas plataformas não se autenticarão em servidores MongoDB que usam certificados x.509 cujos nomes de host são especificados por atributos CommonName.

Map-Reduce

A partir da versão 5.0, o MongoDB descontinuará a operação map-reduce.

Para obter exemplos de alternativas de aggregation pipelines para operações de map-reduce, consulte Map-reduce para aggregation pipeline e Exemplos de map-reduce.

Auditoria

O MongoDB 5.0 adiciona recursos de auditoria que podem ser configurados no tempo de execução.

Se o auditLog.runtimeConfiguration estiver configurado para true, então os arquivos de configuração do mongod e mongos não poderão mais configurar o setParameter.auditAuthorizationSuccess ou configurar filtros de auditoria. Se os arquivos de configuração do servidor contiverem essas configurações, o servidor falhará ao iniciar e registrará um erro.

Se auditLog.runtimeConfiguration for definido como false e houver um documento de configuração de filtro de auditoria, será emitido um aviso de inicialização, mas o servidor não será interrompido.

Reduza o risco de fragmentos obsoletos em transações fragmentadas

A partir do MongoDB 5.0, se você alterar o parâmetro transactionLifetimeLimitSeconds, também deverá alterar transactionLifetimeLimitSeconds para o mesmo valor em todos os membros do conjunto de réplicas do servidor de configuração. Mantendo esse valor consistente:

Garante que o histórico da tabela de roteamento seja mantido por pelo menos o tempo de vida útil da transação nos membros do conjunto de réplicas de shard.
Reduz a frequência de novas tentativas de transação e, portanto, melhora o desempenho.

Alterações gerais

A partir do MongoDB 5.0:

Para featureCompatibilityVersion definido como "5.0" ou superior, os usuários não podem mais gravar diretamente na coleção <database>.system.views.
O comando reIndex e o método de shell do db.collection.reIndex() podem ser executados somente em instâncias independentes.
O número de aggregation pipeline stages permitido em um único pipeline é limitado a 1000.
Soltar a coleção final em um banco de dados (ou descartar o próprio banco de dados) quando directoryPerDB ou --directoryperdb está habilitado exclui o subdiretório recém-vazio desse banco de dados.
O operador de agregação do $subtract converterá o tipo de dados do resultado, se necessário, para representar com precisão o valor do resultado. Consulte $subtract para ver as conversões específicas.
O MongoDB remove a opção de linha de comando --serviceExecutor e a opção de configuração net.serviceExecutor correspondente.
Você não pode autenticar como vários usuários simultâneos na mesma sessão de cliente se a opção --apiStrict estiver definida. A tentativa de autenticação como um novo usuário enquanto estiver conectado como um usuário existente quando a opção --apiStrict estiver definida gerará uma mensagem de erro a cada tentativa de autenticação. Se você não estiver usando a opção --apiStrict, a autenticação como um novo usuário enquanto estiver conectado como um usuário existente gravará um aviso no registro a cada tentativa de autenticação.
A opção pesos é permitida somente para índices do $text.
Você deve definir explicitamente o write concern padrão global antes de tentar reconfigurar um conjunto de réplicas não fragmentadas com uma configuração que altere o write concern padrão implícito. Para definir o write concern padrão global, utilize o comando setDefaultRWConcern.
Para definir o tamanho de replSetOplog em mongosh, use o construtor Double() com o comando replSetResizeOplog.

Itens obsoletos

Obsoleto(a)	Descrição
`mongo`	O shell legado `mongo` foi descontinuado no MongoDB v5.0. A substituição é `mongosh`.
`db.printSlaveReplicationInfo()`	Descontinuado desde a versão 4.4.1: Use `db.printSecondaryReplicationInfo()` em vez disso.
`rs.printSlaveReplicationInfo()`	Descontinuado desde a versão 4.4.1: Use `rs.printSecondaryReplicationInfo()` em vez disso.
`security.clusterIpSourceWhitelist`	Descontinuado na versão 5.0: use `security.clusterIpSourceAllowlist` no lugar.
`--clusterIpSourceWhitelist`	Descontinuado na versão 5.0: use `--clusterIpSourceAllowlist` no lugar.
`logout`	Obsoleto na versão 5.0: desconecte-se do servidor para encerrar sua sessão.
`db.logout()`	Obsoleto na versão 5.0: desconecte-se do servidor para encerrar sua sessão.
Campo de mensagem de auditoria local	Obsoleto na versão 5.0: em vez disso, use o campo `localEndpoint` na mensagem de auditoria ClientMetadata.

Opcodes de protocolo de fio obsoletos

O MongoDB 5.0 descontinua os seguintes opcodes de protocolo de fio:

OP_REPLY
OP_UPDATE
OP_INSERT
OP_QUERY
OP_GET_MORE
OP_DELETE
OP_KILL_CURSORS

Versões mais recentes do driver usam OP_MSG em vez de opcodes obsoletos.

Os comandos e métodos relacionados também são preteridos no MongoDB 5.0:

getLastError
db.getLastError()
db.getLastErrorObj()

Para garantir que o seu driver utiliza o protocolo de fio mais recente, atualize o seu driver para uma versão compatível com o 5.0.

Qualquer código que use explicitamente getLastError, db.getLastError() ou db.getLastErrorObj() deve, em vez disso, usar a API CRUD para emitir a gravação com a preocupação de gravação desejada. As informações sobre o sucesso ou falha da operação de gravação serão fornecidas diretamente pelo condutor como um valor de devolução.

5.0 Compatibilidade de recursos

Alguns recursos do 5.0 exigem não apenas os binários do 5.0, mas também o featureCompatibilityVersion (fCV) definido como 5.0. Esses recursos incluem:

A criação de coleções de séries temporais exige que o FCV seja definido como 5,0+.
A configuração do gerenciamento de filtros de auditoria em tempo de execução exige que o fCV seja definido como 5.0+.
O uso de . e $ em nomes de campos requer fCV definido como 5.0+.
A refragmentação de uma collection requer o fCV definido como 5.0+.

Voltar

5.0

Atualizar 4.4 para 5.0