Alterações de compatibilidade no MongoDB 6.0

allowDiskUse Mudanças

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

$$SEARCH_META Limitações

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 .

Documentos órfãos

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.

Retomar tokens

A partir do MongoDB 6.0.9, os tokens de retomada criados por pipelines de change stream com o novo estágio $changeStreamSplitLargeEvent são incompatíveis com o MongoDB 5.0. Para obter detalhes sobre tokens de retomada, consulte Tokens de retomada.

Filtros

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.

O último índice de chave de fragmento restante não pode ser descartado inadvertidamente

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.

Os índices existentes podem ser eliminados durante a criação de um índice

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.

Chaves de índice de documentos 2dsphere

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.

Formato da chave do índice

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.

Community Edition

• RHEL-72-s390x

$regex Encontrar queries não ignora mais Regex inválido

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.

$regex Comportamento de erro de validação de esquema

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.

Afirmar que a preocupação de gravação em todo o cluster está definida ao iniciar ou adicionar fragmento

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.

rs.reconfig Validação de write concern em todo o cluster

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 .

Autenticação Intra-Cluster

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.

O modo FIPS padroniza a autenticação SCRAM-SHA-1 como desativada

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

O OCSP deve estar ativado

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.

Índices Secundários em Séries Temporais

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

Itens obsoletos

$mod Comportamento de erro

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.

Opcodes legados removidos

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

• OP_INSERT

• OP_DELETE

• OP_UPDATE

• OP_KILL_CURSORS

• OP_GET_MORE

• OP_QUERY

• getLastError

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'

Removidas funções obsoletas de array e string para JavaScript do lado do servidor

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.

Configurações-padrão db.stats()

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.

Filtros e Agrupamentos de Índice

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

Arrays em coleções e visualizações com o comando distinct

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.

Clustered Collections

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.

Bloqueio de gravação do usuário

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.

Coleções de Time Series

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.

Cluster Parameters

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

Dados da política do SELinux

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

Consulte:

• Configurar a política do SELinux na linguagem de definição de dados (DDL)

• Configurar o diretório de dados de política do Enterprise SELinux

Configurações do Key Management Interoperability Protocol (KMIP)

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:

• security.kmip.keyStatePollingSeconds

• security.kmip.activateKeys

Retenção baseada no tempo de fluxos de alterações antes e depois das coleções de imagens

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.

Configurações de criptografia de log de auditoria

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:

• auditLog.auditEncryptionKeyIdentifier

• auditLog.localAuditKeyFile

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.

Altere fluxos com pré e pós-imagens de documentos

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.

Alterar streams com eventos expandidos

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.

LDAP com srv: e srv_raw:

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.

Coleções com campos criptografados

Você deve descartar 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.