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

Alterações de compatibilidade no MongoDB 6.0

Nesta página

  • Agregação
  • Fluxos de alterações
  • Indexes
  • O antigo shell mongo foi removido
  • Suporte a plataformas
  • Expressões regulares
  • Operadores removidos
  • Opções removidas
  • Parâmetros removidos
  • Parâmetros renomeados
  • Comportamento do expireAfterSeconds TTL quando definido como NaN
  • Conjuntos de réplicas
  • Segurança
  • Coleções de Time Series
  • Alterações gerais
  • Considerações de downgrade

Esta página descreve as alterações introduzidas no MongoDB 6.0 que podem afetar a compatibilidade com versões mais antigas do MongoDB.

O MongoDB 6.0 é uma versão principal, o que significa que é compatível com o MongoDB Atlas e sistema on-premises. O MongoDB 6.0 inclui alterações introduzidas nas Rapid Releases do MongoDB 5.1, 5.2 e 5.3. Esta página descreve as alterações de compatibilidade introduzidas nessas Rapid Releases e no MongoDB 6.0.

Para saber mais sobre as diferenças entre as Rapid Releases e versões principais, consulte Versões do MongoDB .

A partir do MongoDB 6.0, os estágios do pipeline que exigem mais de 100 megabytes de memória para execução gravam arquivos temporários no disco por padrão. Esses arquivos temporários duram durante a execução do pipeline e podem influenciar o espaço de armazenamento na sua instância. Em versões anteriores do MongoDB, você deve passar { allowDiskUse: true } para find individuais e comandos aggregate para habilitar esse comportamento.

Somente find e aggregate comandos podem substituir o parâmetro allowDiskUseByDefault por um ou outro:

  • Usando { allowDiskUse: true } para permitir a gravação de arquivos temporários no disco quando allowDiskUseByDefault estiver definido como false

  • Usando { allowDiskUse: false } para proibir a gravação de arquivos temporários no disco quando allowDiskUseByDefault estiver definido como true

A partir do MongoDB 6.0, a variável de agregação Atlas Search $$SEARCH_META pode ser usada em qualquer lugar após um estágio $search em qualquer pipeline, mas não pode ser usada após o estágio $lookup ou $unionWith em qualquer pipeline . A variável de aggregation $$SEARCH_META não pode ser usada em nenhuma etapa subsequente após um estágio $searchMeta .

A partir do MongoDB 5.3, durante a range migration, os eventosde change stream não são gerados para atualizações de documentos órfãos.

A partir do MongoDB 6.0, sempre que possível, os filtros de correspondência são aplicados aos change streams mais cedo do que em versões anteriores. Isso melhora o desempenho. No entanto, quando um filtro for muito restritivo, uma correspondência anterior pode fazer com que uma operação bem-sucedida em versões anteriores falhe na versão 6.0.

A partir do MongoDB 6.0, passar "*" para dropIndexes ou db.collection.dropIndexes() elimina todos os índices , exceto o índice _id e o último índice de chave de fragmento restante, se houver. Tentativas de eliminar explicitamente o último índice de chave shard restante geram um erro.

A partir do MongoDB 5.2, você pode usar dropIndexes ou db.collection.dropIndexes() para eliminar os indexes existentes na mesma coleção, mesmo que haja uma index build em andamento. Em versões anteriores, tentar descartar um índice diferente durante uma construção de índice em andamento resulta em um erro BackgroundOperationInProgressForNamespace.

Para evitar erros de memória, o indexMaxNumGeneratedKeysPerDocument limita o número máximo de chaves de índice de esferas geradas para um único documento.

Consulte indexMaxNumGeneratedKeysPerDocument.

A partir do MongoDB 6.0, foi introduzida uma alteração no formato de chave do índice exclusivo. Se você criar um índice único no MongoDB 6.0, o índice não funcionará com versões MongoDB anteriores a 5.3.2 ou 5.0.7.

O shell do mongo é removido do MongoDB 6.0. A substituição é mongosh.

Começando no MongoDB 5.1.2 as seguintes plataformas já não são mais suportadas:

  • RHEL-72-s390x

A partir do MongoDB 5.1, as opções de$regex options inválidas não são mais ignoradas. Essa alteração torna mais consistente com o uso $regex options de $regex nas queries aggregate de comando e projeção.

A partir do MongoDB 5.1, se uma collection tiver regras de validação de esquema que contenham $regex options inválido, o servidor:

  • Impede todas as operações de inserção e atualização até que as regras de validação do esquema que contêm o padrão regex inválido sejam modificadas com o comando collMod.

  • Escreve um erro de aviso no arquivo de registro do mongod.

A partir do MongoDB 5.1, esses query operators legados são removidos:

Operador removido
Alternativa
$comment
$explain
$hint
$max
$maxTimeMS
$min
$orderby
$query
$returnKey
$showDiskLoc
db.getLastError()
db.getLastErrorObj()
getLastError

O MongoDB 6.0 remove a opção --cpu mongod .

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

Parâmetro removido
Descrição

Esta opção é removida do MongoDB Community Edition. Está disponível no MongoDB Enterprise Edition.

O FIPS não era uma funcionalidade suportada no MongoDB Community Edition. Se a sua instalação utilizou o FIPS mesmo assim, será necessário reconfigurar as conexões TLS/SSL antes de atualizar.

A partir do MongoDB 6.0, os seguintes parâmetros foram renomeados:

Configurar TTL expireAfterSeconds a NaN causa uma mudança de comportamento do MongoDB 4.4 até o MongoDB 6.0 que afeta a sincronização inicial do MongoDB 4.4 e versões anteriores, bem como o mongorestore do MongoDB 4.4 e versões anteriores. Realizar qualquer uma dessas ações faz com que um expireAfterSeconds de NaN seja tratado como um expireAfterSeconds de 0. Dessa forma, pode ocorrer a expiração imediata do documento.

A partir do MongoDB 5.1, ao iniciar, reiniciar ou adicionar um servidor de shard com sh.addShard(), o CWWC (Cluster Wide Write Concern) deve ser definido.

Se o CWWC não estiver definido e o estilhaço estiver configurado de forma que a preocupação de gravação padrão seja { w : 1 } o servidor de estilhaços falhará ao iniciar ou será adicionado e retornará um erro.

Consulte cálculos de write concern padrão para mais detalhes sobre como o write concern padrão é calculado.

A partir do MongoDB 5.1, você deve definir o Cluster Wide Write Concern (CWWC) antes de emitir qualquer que,reconfigs de outra forma, alteraria a preocupação de gravação padrão do novo membro do conjunto de réplicas .

A partir do MongoDB 5.3, o SCRAM-SHA-1 não pode ser usado para autenticação intra-cluster. Somente SCRAM-SHA-256 é suportado.

Em versões anteriores do MongoDB, SCRAM-SHA-1 e SCRAM-SHA-256 podem ser usados para autenticação intra-cluster, mesmo que o SCRAM não esteja explicitamente habilitado.

A partir do MongoDB 5.1, as instâncias em execução no modo FIPS têm o mecanismo de autenticação SCRAM-SHA-1 desabilitado por padrão. Você pode habilitar o mecanismo de autenticação SCRAM-SHA-1 com o setParameter.authenticationMechanisms comando.

Essa alteração não afetará os drives que têm como alvo o MongoDB setFeatureCompatibilityVersion 4,0+.

A partir do MongoDB 6.0, se ocspEnabled estiver definido como true durante a initial sync, todos os nós deverão ser capazes de alcançar o respondente OCSP.

Se um membro falhar no estado STARTUP2, defina tlsOCSPVerifyTimeoutSecs como um valor menor que 5.

Aviso

Se você criar uma coleção de séries temporais fragmentadas no MongoDB 5.1 ou superior, realizar o downgrade para uma versão anterior ao MongoDB 5.0.4 resultará em perda de dados.

Antes de fazer o downgrade para uma versão anterior a 5.0.4, elimine todas as collections de série temporal fragmentadas.

Se houver coleções de séries temporais e você precisar fazer downgrade da versão de compatibilidade de recursos (FCV), primeiro descartará todos os índices secundários que são incompatíveis com o FCV rebaixado. Consulte setFeatureCompatibilityVersion.

Obsoleto(a)
Descrição
O método db.collection.reIndex() é preterido no MongoDB v6.0.
O comando reIndex é preterido no MongoDB v6.0.
Simple network management protocol (SNMP)

A partir do MongoDB 6.0, o SNMP está obsoleto e será removido na próxima versão. Para monitorar sua implantação, use o MongoDB Ops Manager.

Começando no MongoDB 5.1 (e 5.0.4), o operador $mod retornará um erro se os valores divisor ou remainder forem avaliados como determinados valores. Consulte Comportamento do $mod.

O MongoDB 6.0 remove o suporte para os seguintes opcodes e comandos do banco de dados antigos:

Aviso

Atualizar drivers

Para evitar interrupções devido à remoção desses opcodes, atualize seu driver para a versão mais recente.

Se você tentar se conectar a uma instância do MongoDB 3.4 ou mais antiga mongod com um shell do MongoDB 5.1 ou mais recente mongo, receberá uma mensagem de erro como a seguinte:

Connection handshake failed. Is your mongod 3.4 or older?
:: caused by :: network error while attempting to run command
'isMaster' on host '127.0.0.1:27017'

Desde o MongoDB 3.6, os drivers do MongoDB usam OP_MSG em vez de OP_QUERY e os outros opcodes e comandos herdados.

Começando no MongoDB 6.0:

Observação

Comandos de RPC OP_QUERY

O protocolo OP_QUERY RPC pode ser usado com os seguintes comandos:

  • _isSelf

  • authenticate

  • buildinfo

  • buildInfo

  • hello

  • ismaster

  • isMaster

  • saslContinue

  • saslStart

Todos os outros comandos serão rejeitados se forem emitidos como OP_QUERY.

O MongoDB 6.0 atualiza o mecanismo JavaScript interno utilizado para expressões de JavaScript do lado do servidor, $accumulator, $function e $where e de MozJS-60 para MozJS-91. Várias funções de array e string de caracteres não padrão obsoletas que existiam no MozJS-60 são removidas no MozJS-91.

Para obter a lista completa de funções de array e string removidas, consulte as próximas seções nesta página.

Observação

Apenas funções estáticas são removidas

Apenas as funções JavaScript estáticas são removidas. Os equivalentes da função de protótipo das funções removidas ainda podem ser usados.

Por exemplo:

  • Array.concat(<array1>, <array2>) é uma função estática e já não funciona mais no MongoDB 6.0.

  • <array1>.concat(<array2>) é uma função protótipo e ainda funciona no MongoDB 6.0.

Esse comportamento se aplica às funções de array e de string removidas.

A partir do MongoDB 6.0, as seguintes funções de array foram removidas e não pode ser usado no JavaScript do lado do servidor com expressões $accumulator, $function e $where:

  • Array.concat

  • Array.every

  • Array.filter

  • Array.forEach

  • Array.indexOf

  • Array.join

  • Array.lastIndexOf

  • Array.map

  • Array.pop

  • Array.push

  • Array.reduce

  • Array.reduceRight

  • Array.reverse

  • Array.shift

  • Array.slice

  • Array.some

  • Array.sort

  • Array.splice

  • Array.unshift

A partir do MongoDB 6.0, as seguintes funções de array foram removidas e não pode ser usado no JavaScript do lado do servidor com expressões $accumulator, $function e $where:

  • String.charAt

  • String.charCodeAt

  • String.concat

  • String.contains

  • String.endsWith

  • String.includes

  • String.indexOf

  • String.lastIndexOf

  • String.localeCompare

  • String.match

  • String.normalize

  • String.replace

  • String.search

  • String.slice

  • String.split

  • String.startsWith

  • String.substr

  • String.substring

  • String.toLocaleLowerCase

  • String.toLocaleUpperCase

  • String.toLowerCase

  • String.toUpperCase

  • String.trim

  • String.trimLeft

  • String.trimRight

A partir do MongoDB 6.0, o dbStats e o db.stats() só informam o espaço livre atribuído às coleções se o parâmetro estiver definido como 1.

Iniciando no MongoDB 6.0, um filtro de índice utiliza a coleção definida anteriormente utilizando o comando planCacheSetFilter.

A partir do MongoDB 6.0, o comando distinct retorna os mesmos resultados para coleção e views ao usar arrays.

Consulte Arrays em collections e visualizações.

As seções seguintes fornecem informações para remover funcionalidades anteriores incompatíveis de seu sistema. Se você estiver fazendo o downgrade do MongoDB 6.0 para uma versão anterior, revise as seções a seguir para garantir que seu sistema seja executado com sucesso após o downgrade.

A partir do MongoDB 5.3, se você estiver usando clustered collections, deverá eliminar essas coleções antes de fazer o downgrade para uma versão anterior do MongoDB.

A partir do MongoDB 6.0, se você precisar fazer downgrade da versão de compatibilidade de funcionalidades, certifique-se de desabilitar a replicação de cluster para cluster e o bloqueio de escrita do usuário.

Consulte Cluster-to-Cluster Sync e Bloqueio de escrita de usuário.

Você deve descartar coleções de séries temporais antes de fazer downgrade:

  • MongoDB 6.0 ou posterior para MongoDB 5.0.7 ou anterior.

  • MongoDB 5.3 para MongoDB 5.0.5 ou anterior.

Veja as Coleções de séries temporais.

Iniciando no MongoDB 6.0, certifique-se de que todas as operações do setClusterParameter tenham sido concluídas. O downgrade downgrade fCV não poderá ocorrer com êxito se houver operações setClusterParameter em andamento em clusters fragmentados.

A partir do MongoDB 5.1, você deve executar o seguinte comando no diretório no qual a política do SELinux foi clonada anteriormente antes de fazer desatualizar para uma versão anterior do MongoDB:

sudo make uninstall

Começando no MongoDB 6.0, a versão-padrão do protocolo KMIP é 1.2. Para usar a versão 1.0 ou 1.1 do KMIP, use a configuração useLegacyProtocol.

A partir do MongoDB 5.3 Enterprise, se você estiver usando as seguintes configurações KMIP, você deve removê-loas do arquivo de configuração antes de fazer o downgrade para uma versão anterior do MongoDB:

A partir do MongoDB 6.0, se você estiver usando o changeStreamOptions.preAndPostImages.expireAfterSeconds para controlar a retenção baseada em tempo de coleções pré e pós-imagem de fluxos de alteração, você deve garantir que não haja operações setClusterParameter ativas ao fazer o downgrade.

A partir do MongoDB 6.0 Enterprise, se você estiver usando criptografia de registro de auditorias, você deve remover as seguintes configurações do arquivo de configuração antes de fazer o downgrade para uma versão anterior do MongoDB:

Os registros de auditorias criptografados existentes permanecem criptografados e você pode manter qualquer procedimento que você desenvolveu para armazenamento e processamento de registros criptografados.

Consulte Registro de auditorias.

A partir do MongoDB 6.0, se você estiver usando imagens anteriores e posteriores de documentos para change streams, deverá desabilitar changeStreamPreandPostImages para cada coleção usando o collMod comando antes de poder fazer o downgrade para uma versão anterior do MongoDB.

Se o seu aplicativo usar alterar colunas, certifique-se de que não exija a opção showExpandedEvents, que não estará disponível após o downgrade.

Se a configuração do cluster estiver usando os novos tipos de URL "srv:" ou "srv_raw:" em sua configuração LDAP, não será possível reiniciar após um downgrade. Remova os novos tipos de URL da configuração do seu cluster antes de fazer o downgrade.

Você deve abandonar coleções que usam campos criptografados antes de concluir o downgrade do FCV. O downgrade não será concluído se houver coleções usando encryptedFields.

Voltar

6.0