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 comoNaN
- 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.
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() | |
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 |
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:
"majority"
e a opção afterClusterTime está definidaAo 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
, utilizarrs.reconfig()
para alterar a configuração não removerá o camponewlyAdded
. O camponewlyAdded
será anexado à configuração fornecida pelo usuário.replSetGetConfig
removerá todos os camposnewlyAdded
de saída. Se quiser ver quaisquer camposnewlyAdded
, você pode fazer a query da collectionlocal.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.
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.
Leia snapshot
a preocupação sobre cobranças 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 cursor.map()
tipo de devolução de
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 dodb.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çãonet.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
emmongosh
, use o construtorDouble()
com o comandoreplSetResizeOplog
.
Itens obsoletos
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 | |
Descontinuado desde a versão 4.4.1: Use | |
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. |
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+.