Menu Docs
Página inicial do Docs
/
Manual do MongoDB
/ /

Alterações de compatibilidade no MongoDB 5.0

Nesta página

  • Certos comandos aceitam somente parâmetros reconhecidos
  • Comandos removidos
  • Parâmetros removidos
  • Tipos de índice removidos
  • Métricas removidas
  • Suporte a pi de framboesa removido
  • Comportamento TTL expireAfterSeconds quando definido como NaN
  • Mudanças no shell
  • Conjuntos de réplicas
  • Leia a preocupação snapshot sobre cobranças limitadas
  • local é a preocupação de leitura padrão
  • Novo tipo de devolução de cursor.map()
  • Atualizar alterações do operador
  • $setWindowFields Estágio com transações e read concern de snapshots
  • Limites do parâmetro do operador do aggregation pipeline
  • listDatabases Alterações de saída
  • Segurança
  • Map-Reduce
  • Auditoria
  • Reduza o risco de fragmentos obsoletos em transações fragmentadas
  • Alterações gerais
  • 5.0 Compatibilidade de recursos

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

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:

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()
db.collection.save()
Não disponível
Mongo.getSecondaryOk()
Mongo.isCausalConsistency
Não disponível
Mongo.setSecondaryOk()
rs.secondaryOk()
Não disponível
Não disponível

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.

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.

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.

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.

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

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.

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.

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 partir de MongoDB 5.0, secondaryDelaySecs substitui slaveDelay. Esta alteração não é compatível com versões anteriores.

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.

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:

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.

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.

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.

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:

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.

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

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

Obsoleto(a)
Descrição
mongo
O shell legado mongo foi descontinuado no MongoDB v5.0. A substituição é mongosh.

Descontinuado desde a versão 4.4.1: Use db.printSecondaryReplicationInfo() em vez disso.

Descontinuado desde a versão 4.4.1: Use rs.printSecondaryReplicationInfo() em vez disso.

Descontinuado na versão 5.0: use security.clusterIpSourceAllowlist no lugar.
Descontinuado na versão 5.0: use --clusterIpSourceAllowlist no lugar.
Obsoleto na versão 5.0: desconecte-se do servidor para encerrar sua sessão.
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.

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.

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:

Voltar

5.0