Docs Menu
Docs Home
/
Manual de base de datos
/
Notas de versión
Docs Home
/
Manual de base de datos
/
Notas de versión
Docs Home
/
Manual de base de datos
/
Notas de versión

Notas de versión de MongoDB 5.0

Nota

MongoDB 5.0 lanzado el 13 de julio de 2021

Versiones de parches

Advertencia

Limitaciones de versiones pasadas

Los avisos críticos a continuación afectan a algunas versiones anteriores de MongoDB. Si la implementación depende de características afectadas por un aviso crítico, se debe actualizar a la última versión disponible del parche.

Problema
Versiones afectadas

WT-7984

5.0.0 - 5.0.2

WT-7995

5.0.0 - 5.0.2

WT-10461

5.0.0 - 5.0.14 (arquitecturas de sistema ARM64 o POWER)

WT-10551

5.0.2 - 5.0.17 (Copias de seguridad incrementales en clústeres de Ops Manager o Cloud Manager)

SERVIDOR-58936

5.0.0 - 5.0.1

SERVER-60176

5.0.0 - 5.0.21

SERVIDOR-68511

5.0.0 - 5.0.10

SERVIDOR-77506

5.0.0 - 5.0.23

SERVER-80203

5.0.6 - 5.0.21 (Series temporales particionadas por objetos incrustados metaField)

SERVIDOR-82353

5.0.0 - 5.0.24

SERVIDOR-86622

5.0.0 - 5.0.25

5.0.34 - Junio 11, 2026

Importante

MongoDB 5.0.34 contiene una solución para CVE-2026-11933

Para obtener la información más reciente sobre las actualizaciones de seguridad de MongoDB, consulte Boletines de seguridad de MongoDB.

Problemas corregidos:

  • SERVIDOR-128125 Alinear la semántica de propiedad de bsonObjToArray con bsonGetImmutable

  • Todos los problemas de JIRA cerrados en 5.0.34

  • 5.0.34 Registro de cambios

5.0.33 - 12 de mayo de 2026

Importante

MongoDB 5.0.33 contiene una solución para CVE-2026-8053.

Para obtener la información más reciente sobre las actualizaciones de seguridad de MongoDB, consulte Boletines de seguridad de MongoDB.

Problemas corregidos:

5.0.32 - 19 de diciembre de 2025

Importante

MongoDB 5.0.32 contiene una solución para CVE-2025-14847.

Para obtener la información más reciente sobre las actualizaciones de seguridad de MongoDB, consulte Boletines de seguridad de MongoDB.

Problemas corregidos:

  • SERVIDOR-115508: Crea buffers de tamaño mínimo para Mensajes sin comprimir

5.0.31 - Jan 28, 2025

5.0.30 - 24 de octubre de 2024

Importante

La neutralización inadecuada de bytes nulos puede llevar a sobrelecturas de búfer en MongoDB Server.

En MongoDB 5.0 y 5.0.30, un usuario autorizado puede activar fallos o recibir el contenido de sobrelecturas de búfer de la memoria del servidor al emitir solicitudes especialmente diseñadas que construyan BSON malformados en MongoDB Server.

Este problema afecta a las versiones de MongoDB Server:

  • 5.0.0 - 5.0.29

  • 6.0.0 - 6.0.18

  • 7.0.0 - 7.0.14

  • 8.0.0 - 8.0.2

5.0.29 - 30 de septiembre de 2024

Importante

Corrección para CSFLE y Queryable Encryption: la autoconsulta puede enviar valores en subpipelines como texto sin formato en lugar de texto cifrado.

Debido a CVE-2024-8013, en MongoDB 5.0 antes de la 5.0.28, un error en el análisis de consultas de ciertos $lookup subpipelines puede resultar en que los valores literales de las expresiones para campos cifrados se envíen al servidor de forma incorrecta.

Si esto ocurre, no se devolverán ni se escribirán documentos. Este problema afecta al binario mongocryptd y a la biblioteca compartida mongo_crypt_v1 en las siguientes versiones de MongoDB Server:

  • 7.3.0 - 7.3.3

  • 7.0.0 - 7.0.11

  • 6.0.0 - 6.0.16

  • 5.0.0 - 5.0.28

Puntuación CVSS: 2.2

CWE: CWE-319: Transmisión de información confidencial en texto no cifrado

5.0.28 - 15 de julio de 2024

5.0.27 - Jun 04, 2024

5.0.26 - 26 de marzo de 2024

5.0.25 - Feb 28, 2024

Importante

La corrección para MongoDB Server podría permitir una conexión no confiable exitosa

Debido a CVE-2024-1351, en MongoDB 5.0 anterior a 5.0.25, bajo ciertas configuraciones de --tlsCAFile y CAFile, MongoDB Server puede omitir la validación del certificado de igual, lo que puede dar como resultado que las conexiones no confiables se realicen con éxito.

Esto puede reducir de manera efectiva las garantías de seguridad proporcionadas por TLS y abrir conexiones que deberían haberse cerrado debido a la falla en la validación del certificado. Este problema afecta a las siguientes versiones de MongoDB Server:

  • 7.0.0 - 7.0.5

  • 6.0.0 - 6.0.13

  • 5.0.0 - 5.0.24

  • 4.4.0 - 4.4.28

Puntuación CVSS: 8.8

CWE: CWE-295: validación incorrecta del certificado

5.0.24 - Jan 18, 2024

  • SERVIDOR-50792 Devolver errores más útiles cuando no se pueda encontrar un índice de clave de partición para shardCollection/refineCollectionShardKey

  • SERVER-77506 Las transacciones multi-documento particionadas pueden no coincidir con los datos y ShardVersion.

  • SERVIDOR-81878 startupRecoveryForRestore podría no funcionar correctamente si se aplica un descartar de colección durante la recuperación de inicio

  • SERVER-83091 El query $or puede activar un bucle infinito durante la enumeración del plan.

  • WT-7929 Investigar una solución para evitar bloqueos del FTDC durante el punto de control.

  • Todos los problemas de JIRA cerrados en 5.0.24

  • 5.0.24 Registro de cambios

5.0.23 - 27 de noviembre del 2023

5.0.22 - 26 de octubre de 2023

5.0.21 - 12 de septiembre de 2023

  • SERVER-60466 Los driver de soporte difunden $clusterTimes firmados a set de réplicas --shardsvrs antes de ejecutar addShard.

  • SERVIDOR-71627 La información actualizada de la ruta de la colección en caché bloqueará severamente todas las solicitudes de los clientes cuando un clúster tenga 1 millones de fragmentos

  • SERVER-78813 La propagación del punto de confirmación falla indefinidamente con cursores exhaustivos con lastCommitted optime nulo

  • WT-10759 No vuelva a intentar forzar la expulsión de páginas del historial durante la reconciliación

  • WT-11051 Corregir la comparación del timestamp duradero más reciente de inicio en la validación de timestamp agregada

  • Todos los asuntos JIRA cerrados en 5.0.21

  • 5.0.21 Registro de cambios

5.0.20 - Aug 14, 2023

  • SERVER-74954 Resultado incorrecto cuando $or contiene o reescribe la condición extra de $elemMatch.

  • SERVER-78813 La propagación del punto de confirmación falla indefinidamente con cursores exhaustivos con lastCommitted optime nulo

  • SERVER-79136 Resultado incorrecto de query de $match + $group en metaField sobre serie de tiempo.

  • WT-10449 No guardar la cadena de actualizaciones cuando no haya actualizaciones que deban almacenarse en el historial

  • WT-11031 Corregir RTS para saltarse tablas sin información de ventana de tiempo en el punto de control.

  • Todos los issues de JIRA cerrados en 5.0.20

  • 5.0.20 Registro de Cambios

5.0.19 - 13 de julio de 2023

5.0.18 - 18 de mayo de 2023

Problemas corregidos:

5.0.17 - Apr 27, 2023

Problemas corregidos:

5.0.16 - Apr 10, 2023

Problemas corregidos:

5.0.15 - Feb 27, 2023

Problemas corregidos:

5.0.14 - 21 de nov, 2022

Problemas corregidos:

5.0.13 - 29 de septiembre de 2022

Problemas corregidos:

  • SERVIDOR-69611 Establecer la opción del compilador -ffp-contract=off por defecto.

  • SERVER-69220 refineCollectionShardKey permite alternar los campos actuales de claves de partición entre aquellos basados en rango y aquellos encriptadas, lo que puede llevar a inconsistencias de datos

  • SERVIDOR-67650 El destinatario de redistribución puede devolver remainingOperationTimeEstimatedSecs=0 cuando el aplicador de oplog no ha alcanzado al buscador de oplog

  • SERVER-68094 El redistribución de fragmentos con _id personalizado falla con un error de proyección

  • WT-9870 Corrige la actualización de la marca de tiempo fijada cada vez que se actualice la marca de tiempo más antigua durante la recuperación

  • Todos los problemas de JIRA cerrados en 5.0.13

  • 5.0.13 Registro de cambios

5.0.12 - 05 Sep 2022

Problemas corregidos:

5.0.11 - Aug 19, 2022

Problemas corregidos:

  • SERVIDOR-68511 La actualización MovePrimary de la entrada config.databases debe usar la notación de campos punteados.

  • SERVER-61321 Mejorar el manejo de valores grandes o NaN para la versión del índice de texto

  • SERVIDOR-60607 Mejora el manejo de valores grandes/NaN para la versión del índice geográfico

  • SERVIDOR-68628 Reintentar una operación fallida de redistribución después de una transferencia principal puede provocar el fallo del servidor o la pérdida de guardados

  • SERVIDOR-68522 Prevenir 5.0 binario a partir de la compatibilidad de características entre versiones 4.4 con un índice TTL mal configurado

  • WT-9500 Corregir RTS para usar la ventana de tiempo de celda en lugar de los timestamps de clave/valor de la actualización del HS

  • Todos los problemas de JIRA se cerraron en la versión 5.0.11

  • 5.0.11 Registro de cambios

5.0.10 - 29 de julio de 2022

Problemas corregidos:

5.0.9 - 31 de mayo de 2022

Problemas corregidos:

5.0.8 - Apr 25, 2022

Problemas corregidos:

  • SERVER-63531 commitQuorum incluye incorrectamente nodos buildIndexes:false y el mensaje de error indica incorrectamente que solo los nodos con derecho a voto son aptos

  • SERVER-63387 1 StreamingCursor debe devolver bloques de copia de seguridad en el orden en que se recuperaron del cursor de copia de seguridad WiredTiger

  • SERVIDOR-62229 Arreglar la invariante al aplicar entradas de creación de índices mientras recoverFromOplogAsStandalone=true

  • SERVER-61879 Las actualizaciones para recuperar migraciones nunca deben unirse a actualizaciones en curso

  • WT-8924 No verifiques la ventana de tiempo en disco si hay una lista de inserciones al comprobar conflictos en el almacén de filas

  • Todas las incidencias JIRA cerradas en la 5.0.8

  • 5.0.8 Changelog

5.0.7 - Apr 11, 2022

Problemas corregidos:

5.0.6 - Jan 31, 2022

Problemas corregidos:

5.0.5 - 6 de diciembre de 2021

Problemas corregidos:

5.0.4 - 15 de noviembre de 2021

Problemas corregidos:

5.0.3 - 21 de septiembre de 2021

Problemas corregidos:

  • SERVIDOR-57667: Mejorar la velocidad de procesamiento del pipeline de clonación de colecciones en el redimensionamiento

  • SERVIDOR -57630: Activar SSL_OP_NO_RENEGOTIATION en Ubuntu 18.04 cuando se ejecuta con OpenSSL 1.1.1

  • WT-8005: Corrige un error de confirmación de preparación que podría dejar sin resolver la entrada del historial de la tienda

  • WT-7995: Corrige la visibilidad global para que no pueda exceder la visibilidad de punto de control

  • WT-7984: Solucionar un error que podría causar que un punto de control omita una página de datos

  • Todos los issues de JIRA cerrados en 5.0.3

  • 5.0.3 Registro de cambios

5.0.2 - Aug 4, 2021

Problemas corregidos:

5.0.1 - 22 de julio de 2021

Problemas corregidos:

5.0.0 - 13 de julio de 2021

El resto de esta página proporciona las notas de versión 5.0.0:

Colecciones de series de tiempo

MongoDB 5.0 introduce colecciones de series temporales que almacenan eficientemente secuencias de mediciones durante un período de tiempo. En comparación con las colecciones normales, almacenar datos de series de tiempo en colecciones de series de tiempo mejora la eficiencia de las queries y reduce el uso de disco para tus datos e índices.

Agregación

Nuevos operadores de agregación

MongoDB 5.0 introduce los siguientes operadores de agregación:

Operador
Descripción

$count

$count (aggregation accumulator) proporciona un conteo de todos los documentos cuando se utiliza en la etapa $group (aggregation) existente del pipeline y en la nueva etapa $setWindowFields de MongoDB 5.0.

La $count (aggregation accumulator) es distinta de la etapa de pipeline $count (aggregation).

$dateAdd

Incrementa un objeto Date en una cantidad especificada de unidades de tiempo.

$dateDiff

Devuelve la diferencia entre dos fechas.

$dateSubtract

Disminuye un objeto Fecha en un número especificado de unidades de tiempo.

$dateTrunc

Trunca una fecha.

$getField

Devuelve el valor de un campo especificado de un documento. Se puede usar $getField para recuperar el valor de los campos cuyos nombres contienen puntos (.) o comienzan con signos de dólar ($).

$rand

El método genera un valor flotante aleatorio entre 0 $rand $sampleRate y 1 $randcada vez que se invoca. El nuevo operador se basa en.

$sampleRate

Agrega el método $sampleRate para seleccionar probabilísticamente documentos de un pipeline a un ritmo determinado.

$setField

Añade, actualiza o remueve un campo especificado en un documento. Puede usar $setField para añadir, actualizar o remover campos con nombres que contengan puntos (.) o comiencen con signos de dólar ($).

$unsetField

Remueve un campo especificado en un documento. Un alias para $setField que remueve campos con nombres que contienen puntos (.) o que comienzan con signos de dólar ($).

Operadores de ventana

MongoDB 5.0 introduce la etapa de pipeline $setWindowFields, que permite realizar operaciones en un rango especificado de documentos dentro de una colección, denominado una ventana. La operación devuelve los resultados basados en el operador de ventanaelegido.

Por ejemplo, puedes usar la etapa $setWindowFields para entregar el:

  • Diferencia de ventas entre dos documentos de una colección.

  • Clasificaciones de ventas.

  • Totales de ventas acumuladas.

  • Análisis de información compleja de series de tiempo sin exportar los datos a una base de datos externa.

Mejoras generales de agregación

$expr Operador: los operadores de comparación utilizan índices

A partir de MongoDB 5.0, los operadores $eq, $lt, $lte, $gt y $gte colocados en un operador $expr pueden utilizar índices para mejorar el rendimiento.

$ifNull La expresión acepta varias expresiones de entrada

A partir de MongoDB 5.0, se pueden especificar múltiples expresiones de entrada para la expresión $ifNull antes de devolver una expresión de reemplazo.

let Opción para la agregación

A partir de MongoDB 5.0, el comando aggregate y el método asistente db.collection.aggregate() disponen de una opción let para especificar una lista de variables que pueden ser utilizadas en otras partes de la canalización de agregación. Esto permite mejorar la legibilidad de los comandos al separar las variables del texto de la query.

$lookup Etapa: subconsultas correlacionadas concisas

A partir de MongoDB 5.0, una etapa de $lookup de la pipeline de agregación admite subconsultas correlacionadas concisas que mejoran las uniones entre colecciones.

$lookup Etapa: subconsultas no correlacionadas

A partir de MongoDB 5.0, para una subconsulta no correlacionada en una etapa de canalización $lookup que contiene una etapa $sample, el operador $sampleRate o el operador $rand, la subconsulta siempre se ejecuta de nuevo si se repite. Anteriormente, según el tamaño de la salida de la subquery, se almacenaba en caché la salida de la subquery o se volvía a ejecutar la subquery.

Consulta Realiza una subconsulta no correlacionada con $lookup.

$sort Etapa: Mejoras de rendimiento

A partir de MongoDB 5.0, el optimizador del query transfiere los resultados de una etapa $project a la etapa $sort. Como resultado, $sort las operaciones pueden requerir menos RAM cuando se utilizan con la etapa project y evitar los errores Sort exceeded memory limit.

Auditoría

Configuración del filtro de auditoría en tiempo de ejecución

MongoDB 5.0 añade la capacidad de configurar filtros de auditoría en tiempo de ejecución.

Operador
Descripción

auditConfigPollingFrequencySecs

Define el intervalo de sondeo para comprobar la configuración de auditoría

getAuditConfig

Recupera las configuraciones de auditoría de mongod y mongos.

setAuditConfig

Establece nuevas configuraciones de auditoría para mongod y las instancias mongos durante la ejecución.

Actualizaciones generales de auditoría

A partir de MongoDB 5.0:

Colecciones con tamaño fijo

Las eliminaciones de colección con tamaño fijo se replican en los secundarios

A partir de MongoDB 5.0, las operaciones implícitas de eliminación de los sets de réplica y las colecciones con tamaño fijo son procesadas por el primario y replicadas a los nodos secundarios.

Eliminaciones explícitas permitidas en colecciones con tamaño fijo

A partir de MongoDB 5.0.7, puede eliminar documentos de las colecciones limitadas mediante los métodos de eliminación.

Flujos de cambio

Cambiar salida de eventos

A partir de MongoDB 5.0, los eventos de cambio contienen el campo updateDescription.truncatedArrays para registrar truncamientos de arreglos.

Indexes

Cambio en el comportamiento de los índices parciales

A partir de MongoDB 5.0, se pueden crear múltiples "índices parciales" utilizando el mismo "patrón de clave" siempre que los campos partialFilterExpression no expresen filtros equivalentes.

En versiones anteriores de MongoDB, no se permite crear múltiples índices parciales al utilizar el mismo patrón de clave con diferentes expresiones de filtro parciales.

Cambio en el comportamiento único del índice disperso

A partir de MongoDB 5.0, pueden existir índices únicos dispersos e índices únicos no dispersos con el mismo patrón de clave en una sola colección.

Consulta creación única de índices dispersos

No se pueden descartar Ready índices durante la creación de índices en curso.

El comando db.collection.dropIndexes() no puede descartar índices listos si hay alguna creación de índices en curso.

  • En las versiones 4.4.0-4.4.4 de MongoDB, esta lógica no era cierta debido a un error.

La validación en primer plano puede corregir inconsistencias en los metadatos multiclave

Cuando se ejecutar en una implementación de MongoDB, db.collection.validate() intenta corregir inconsistencias de metadatos multikey de implementaciones autónomas.

Eliminación del Índice geoHaystack y el Comando geoSearch

MongoDB 5.0 remueve el índice geoHaystack y el comando geoSearch en desuso. Utilizar un índice 2d con $geoNear o uno de los operadores del query geoespacial admitidos en su lugar.

Si se cambia la instancia de MongoDB a 5.0 y se configura featureCompatibilityVersion en 5.0, se borrarán todos los índices de geoHaystack preexistentes.

Nuevos mensajes de error

Las operaciones db.collection.createIndex() y db.collection.createIndexes() tienen nuevos mensajes de error cuando se especifican incorrectamente las opciones.

Creación de índices interrumpidas

Si un nodo de un set de réplicas se apaga correctamente o se revierte durante la creación de un índice, el progreso de la creación del índice ahora se guarda en el disco. Cuando el servidor se reinicie, la creación de índices se reanudará desde la posición guardada.

reIndex Cambio de comportamiento

A partir de MongoDB 5.0, el comando reIndex y el método de shell db.collection.reIndex() solo se pueden ejecutar en instancias autónomas.

Comandos removidos

A partir de MongoDB 5.0, se eliminarán los siguientes comandos de base de datos y mongo métodos auxiliares de shell:

Comando eliminado
Alternativa

db.collection.ensureIndex()

db.collection.createIndex()

db.resetError()

No disponible

resetError

No disponible

shardConnPoolStats

connPoolStats

unsetSharding

No disponible

geoSearch

$geoNear o uno de los operadores de consulta geoespacial compatibles

Sets de réplicas

Lecturas no transaccionales activadas config.transactions

A partir de MongoDB 5.0, no se permiten lecturas no transaccionales en la colección config.transactions con los siguientes niveles de consistencia de lectura y opciones:

hello Comando

A partir de MongoDB 5.0, se introdujeron el comando hello y el método db.hello() como reemplazos del comando isMaster y el método db.isMaster(). La nueva métrica de topología connections.exhaustHello rastrea esto en connections.

Período de reposo

A partir de MongoDB 5.0, mongod y mongos entran en un periodo de inactividad para permitir que cualquier operación en curso de la base de datos se complete antes de cerrar.

Límite eliminado para members[n]._id valores

A partir de MongoDB 5.0, el campo members[n]._id puede ser cualquier valor entero mayor o igual a 0. Anteriormente, este valor se limitaba a un número entero entre 0 y 255 inclusive.

enableMajorityReadConcern No es configurable

A partir de MongoDB 5.0, enableMajorityReadConcern y --enableMajorityReadConcern no se pueden cambiar y siempre se establecen en true debido a mejoras en el motor de almacenamiento.

En versiones anteriores de MongoDB, enableMajorityReadConcern y --enableMajorityReadConcern son configurables y se pueden establecer en false para evitar que la presión sobre la caché de almacenamiento inmovilice una implementación con una arquitectura de primario-secundario-árbitro (PSA) de tres miembros.

Si está utilizando una arquitectura de tres nodos de primario-secundario-árbitro (PSA), considere lo siguiente:

  • El nivel de confirmación de escritura "majority" puede causar problemas de rendimiento si un secundario no está disponible o está retrasado. Para obtener consejos sobre cómo mitigar estos problemas, consulta Mitigar problemas de rendimiento con un set de réplicas de PSA autogestionado.

  • Si estás utilizando un "majority" global por defecto y el nivel de confirmación de escritura es menor que el tamaño de la mayoría, tus consultas pueden devolver datos obsoletos (no completamente replicados).

Control mejorado de tiempo de espera del pool de hilos

A partir de MongoDB 5.0, puedes utilizar el nuevo parámetro de servidor replWriterMinThreadCount para permitir que los hilos inactivos por encima de este mínimo sean cerrados. Cuando replWriterMinThreadCount se configura con un valor inferior a replWriterThreadCount, los hilos inactivos por encima de replWriterMinThreadCount se cancelan por tiempo de espera.

Reconfiguración de sets de réplicas de PSA

Al reconfigurar sets de réplicas primario-secundario-árbitro (PSA) o cambiar a una arquitectura PSA, ahora en algunos casos es necesario realizar la reconfiguración en un cambio de dos pasos. MongoDB 5.0 introduce el método rs.reconfigForPSASet(), que realiza ambos pasos. Si no puedes usar el método asistente, sigue el procedimiento en Modificar de manera segura un set de réplicas PSA autogestionado.

Limitar las reevaluaciones de la fuente de sincronización

maxNumSyncSourceChangesPerHour determina cuántos cambios en el origen de sincronización pueden ocurrir por hora antes de que el nodo deje temporalmente de revaluar un origen de sincronización. Este parámetro no impedirá que un nodo comience a sincronizarse desde otro nodo si no tiene una fuente de sincronización.

enableOverrideClusterChainingSetting Server Parameter

A partir de MongoDB 5.0.2, puedes establecer el nuevo parámetro del servidor enableOverrideClusterChainingSetting en true para permitir que los miembros secundarios repliquen datos de otros miembros secundarios incluso si settings.chainingAllowed está en false.

Seguridad

Soporte para la rotación de certificados en línea

A partir de MongoDB 5.0, puede rotar los siguientes certificados TLS on-demand sin necesidad de detener primero su instancia en uso de mongod ni de mongos:

Para rotar estos certificados, sustituye los archivos de certificados en tu sistema de archivos por versiones actualizadas y, a continuación, utiliza el comando rotateCertificates o el método shell db.rotateCertificates() para activar la rotación de certificados.

Rotar los certificados de esta manera no requiere tiempos de inactividad y no descarta ninguna conexión remota activa.

Consulte Rotación de certificados en línea para obtener todos los detalles.

Compatibilidad para configurar los conjuntos de cifrado TLS 1.3

MongoDB 5.0 introduce el parámetro opensslCipherSuiteConfig para permitir la configuración de los conjuntos de cifrados soportados que OpenSSL debe permitir al usar el cifrado TLS 1.3.

Advertencia de inicio de conexión TLS con certificado X509

A partir de MongoDB 5.0, mongod y mongos ahora emiten una advertencia de inicio cuando sus certificados no incluyen un atributo Nombre Alternativo del Sujeto.

Las siguientes plataformas no admiten la validación de nombres comunes:

  • iOS 13 y superior

  • MacOS 10.15 y superior

  • Go 1.15 o superior

Los clientes que usan estas plataformas no se autenticarán en los servidores de MongoDB que usan certificados X.509 cuyos nombres de host están especificados por los atributos CommonName.

Acción de privilegio de ApplyOps

MongoDB 5.0 introduce la acción de privilegio applyOps que se hereda por dbAdminAnyDatabase.

La acción applyOps permite a los usuarios ejecutar el comando de base de datos applyOps.

Clústeres fragmentados

Redistribución

La clave de partición ideal permite a MongoDB distribuir los documentos uniformemente por todo el clúster y, al mismo tiempo, facilitar patrones de query comunes. Una clave de partición subóptima puede causar problemas de rendimiento o escalado debido a una distribución desigual de los datos. A partir de MongoDB 5.0, puedes usar el comando reshardCollection para cambiar la clave de partición de una colección para cambiar la distribución de tus datos en todo tu clúster.

currentOp Informa sobre las operaciones de reasignación en curso

Desde MongoDB 5.0, la etapa de agregación $currentOp (y el comando currentOp y el método de shell db.currentOp()) incluyen información adicional sobre el estado de las operaciones de reparticionamiento en curso para el coordinador de reparticionamiento y las particiones donantes y receptoras.

db.currentOp El método ahora utiliza una etapa de agregación en mongosh

A partir de MongoDB 5.0, la etapa de agregación $currentOp se usa al ejecutar el método asistente db.currentOp() con mongosh.

mongos / mongod Pool de conexiones

A partir de MongoDB 5.0, MongoDB añade la opción de parámetro "automatic" como nuevo valor por defecto para el ShardingTaskExecutorPoolReplicaSetMatching. Cuando se establece para un mongos, la instancia sigue el comportamiento especificado para la opción "matchPrimaryNode". Cuando se configura para un mongod, la instancia sigue el comportamiento especificado para la opción "disabled".

renameCollection Compatible con colecciones particionadas

A partir de MongoDB 5.0, se puede usar el comando renameCollection para cambiar el nombre de una colección particionada.

Al cambiar el nombre de una colección particionada o no particionada en un clúster, las colecciones de origen y destino se bloquean exclusivamente en cada partición. Las operaciones posteriores en las colecciones de origen y destino deben esperar hasta que se complete la operación de cambio de nombre.

movePrimary Mensaje de error para escrituras durante la operación

A partir de MongoDB 5.0, al utilizar el comando movePrimary para remover una partición de un clúster, los escritos en la partición original generarán un mensaje de error.

División y fusión de registros de cambios de fragmentos, mostrar partición propietaria

A partir de MongoDB 5.0, los documentos en la colección config.changelog para operaciones de división y merge contienen un campo owningShard. El campo owningShard muestra el shardId de la partición propietaria de los fragmentos que se dividieron o fusionaron.

El campo owningShard ayuda a identificar las particiones donde las operaciones de división o fusión ocurren con frecuencia.

maxCatchUpPercentageBeforeBlockingWrites Server Parameter

A partir de MongoDB 5.0, puedes establecer el maxCatchUpPercentageBeforeBlockingWrites para especificar el porcentaje máximo permitido de datos que aún no se han migrado durante una operación de moveChunk en comparación con el tamaño total (en MBs) del fragmento que se está transfiriendo.

Este parámetro puede afectar el comportamiento de:

Cambios en el shell

Nuevo MongoDB Shell: mongosh

El shell mongo ha quedado obsoleto en MongoDB v5.0. El shell de reemplazo es mongosh. El shell heredado mongo será retirado en una versión futura.

El empaquetado de shell también cambia en MongoDB v5.0. Consulta las instrucciones de instalación para obtener más detalles.

Soporte de Shell para proveedores de KMS de GCP y Azure

A partir de MongoDB 5.0, la Google Cloud Platform KMS y Azure Key Vault son compatibles tanto con mongosh como con la shell mongo heredada como proveedores de Key Management Service (KMS) para cifrado a nivel de campo del lado del cliente.

Mediante el uso de un KMS, usted puede almacenar de forma centralizada y segura las claves maestras de cliente (CMK), que se utilizan para cifrar y descifrar claves de cifrado de datos como parte del proceso de cifrado a nivel de campo del lado del cliente.

Además, un KMS configurado permite el uso de Cómo CSFLE desencripta documentos de los campos de datos cuando se usan con MongoDB Enterprise.

Para aprender más, vea Configure un proveedor de KMS utilizando mongosh.

Snapshots

Soporte extendido para nivel de consistencia de lectura "snapshot"

A partir de MongoDB 5.0, el nivel de consistencia de lectura "snapshot" es compatible con algunas operaciones de lectura fuera de transacciones multi-documento en primarios y secundarios. Consulta Realizar consultas de snapshot de larga duración.

minSnapshotHistoryWindowInSeconds Server Parameter

A partir de MongoDB 5.0, puedes usar el parámetro minSnapshotHistoryWindowInSeconds para controlar durante cuánto tiempo WiredTiger conserva el historial de instantáneas.

Transacciones

coordinateCommitReturnImmediatelyAfterPersistingDecision Parameter

El parámetro del servidor coordinateCommitReturnImmediatelyAfterPersistingDecision controla cuándo se devuelven las decisiones de confirmación de transacción al cliente.

El parámetro se introdujo en MongDB 5.0 con un valor por defecto de true. En MongoDB 6.0 y 5.0.10, el valor por defecto cambia a false.

Cuando coordinateCommitReturnImmediatelyAfterPersistingDecision es false, el coordinador de la transacción de partición espera a que todos los participantes confirmen el commit de una transacción multidocumento antes de comunicar la decisión de commit al cliente.

Cambios de denominación

A partir de febrero de 2022, la terminología "API versionada" cambió a "API estable". Todos los conceptos y funcionalidades siguen siendo los mismos con este cambio de nombre.

Cambios generales

Estadísticas del Plan de Ejecución para Consulta con $lookup pipeline Stage

MongoDB 5.0 añade estadísticas del plan de ejecución para las consultas que utilizan una etapa $lookup de pipeline.

Manejo mejorado de ($) y (.) en nombres de campos

MongoDB 5.0 añade soporte mejorado para nombres de campos que están precedidos por ($) o que contienen (.) caracteres. Las reglas de validación para almacenar datos se han actualizado para facilitar el trabajo con fuentes de datos que utilizan estos caracteres.

Nivel de confirmación de escritura (write concern) por defecto en todo el clúster

A partir de MongoDB 5.0, una vez que el Cluster Wide Write Concern (CWWC) se establece a través del comando setDefaultRWConcern, el nivel de confirmación de escritura (write concern) no se puede deshacer.

Nivel de confirmación de escritura por defecto implícito

A partir de MongoDB 5.0, el nivel de confirmación de escritura (write concern) predeterminado implícito es w: majority. Sin embargo, existe un caso excepcional para las implementaciones de set de réplicas que contienen árbitros:

  • La mayoría de los votos de un conjunto de réplicas es igual a 1 más la mitad del número de miembros con derecho a voto, redondeada hacia abajo. Si el número de miembros con derecho a voto que contienen datos no es mayor que la mayoría de los votos, el nivel de confirmación de escritura por defecto es { w: 1 }.

  • En todos los demás escenarios, el nivel de confirmación de escritura por defecto es { w: "majority" }.

Específicamente, MongoDB usa la siguiente fórmula para determinar el nivel de confirmación de escritura por defecto:

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

Por ejemplo, considera las siguientes implementaciones y sus respectivos niveles de confirmación de escritura por defecto:

Non-Arbiters
Árbitros
Nodos de votación
Mayoría de nodos de votación
Nivel de confirmación de escritura por defecto implícito

2

1

3

2

{ w: 1 }

4

1

5

3

{ w: "majority" }

  • En el primer ejemplo:

    • Hay 2 miembros no árbitros y 1 árbitro, para un total de 3 nodos con derecho a voto.

    • La mayoría de los nodos de votación (1 más la mitad de 3, redondeado hacia abajo) es 2.

    • El número de miembros no árbitros (2) es igual a la mayoría de los nodos de votación (2), lo que genera un nivel de confirmación de escritura implícita de { w: 1 }.

  • En el segundo ejemplo:

    • Hay 4 miembros no árbitros y 1 árbitro para un total de 5 nodos de votación.

    • La mayoría de los nodos de votación (1 más la mitad de 5, redondeado hacia abajo) es 3.

    • El número de miembros que no son árbitros (4) es mayor que la mayoría de los nodos con derecho a voto (3), lo que resulta en un nivel de confirmación de escritura implícito de { w: "majority" }.

La { w: "majority" } nivel de confirmación de escritura (write concern) por defecto proporciona una garantía de mayor durabilidad en caso de una elección, o si los miembros del set de réplicas no están disponibles.

mongosShutdownTimeoutMillisForSignaledShutdown Parameter

A partir de MongoDB 5.0, el nuevo parámetro mongosShutdownTimeoutMillisForSignaledShutdown especifica el tiempo en milisegundos para esperar a que se completen las operaciones actuales de la base de datos antes de iniciar el apagado de mongos.

Nivel de compresión zstd configurable

MongoDB 5.0 introduce la opción de archivo de configuración zstdCompressionLevel que permite niveles de compresión configurables cuando blockCompressor se establece en zstd.

Operaciones de lectura sin bloqueo

A partir de MongoDB 5.0, las siguientes operaciones de lectura no se bloquean cuando otra operación mantiene un bloqueo de escritura exclusivo (X) en la colección:

Al guardar en una colección, mapReduce y aggregate mantienen un bloqueo de intento exclusivo (IX). Por lo tanto, si ya se tiene un bloqueo exclusivo X sobre una colección, mapReduce y aggregate las operaciones de guardado están bloqueadas.

Explicación de las fallas de validación de esquema

MongoDB 5.0 agrega explicaciones detalladas cuando un documento no supera la validación del esquema.

Opción de reparación en el comando validate

A partir de MongoDB 5.0, el comando validate y el método db.collection.validate() asistente tienen una nueva opción de repair para reparar una colección que tiene inconsistencias.

El comando validate y el método asistente db.collection.validate() también devuelven un nuevo valor booleano repaired que será true si se reparó la colección.

validate Informes de comandos Violaciones del esquema de documentos

A partir de MongoDB 5.0, validate y db.collection.validate() validan documentos en una colección. Los comandos informan si se violan reglas de validación de esquemas.

Opción de reparación en mongod

A partir de MongoDB 5.0, la opción --repair para mongod valida las colecciones para encontrar cualquier inconsistencia y las corrige si es posible, lo que evita la reconstrucción de los índices. Consulta la opción --repair para conocer el uso y las limitaciones.

corruptRecords Campo en la salida de validación

A partir de MongoDB 5.0, el comando validate y el método auxiliar db.collection.validate() devuelven un nuevo campo corruptRecords que contiene un arreglo de valores RecordId para documentos corruptos.

maxValidateMemoryUsageMB Server Parameter

A partir de MongoDB 5.0, el comando setParameter tiene un nuevo parámetro maxValidateMemoryUsageMB, que establece el uso máximo de memoria para el comando validate.

findChunksOnConfigTimeoutMS Server Parameter

A partir de MongoDB 5.0, puedes utilizar el findChunksOnConfigTimeoutMS parámetro para cambiar el tiempo de espera para las operaciones de búsqueda en chunks.

Opción del perfilador de base de datos filter

A partir de MongoDB 5.0, se puede establecer una opción filter para que el perfilador de base de datos determine qué operaciones se perfilan y registran. Se puede usar la expresión filter en lugar de las opciones de perfilador slowms y sampleRate .

Consulte:

Registrar cambios en las configuraciones del perfilador de bases de datos

A partir de MongoDB,5.0 los cambios realizados en el perfilador de base level slowmsdesampleRate datos,,, o filter mediante el profile comando o db.setProfilingLevel() el método contenedor se registran en log file el.

Rotación de registros independiente para registros de servidor y auditoría

A partir de MongoDB 5.0, cuando la función de auditoría está activada, ahora puedes rotar los registros del servidor y de la auditoría de forma independiente mediante el comando logRotate. Anteriormente, logRotate rotaba ambos registros juntos.

remote Campo en los registros de operaciones lentas

A partir de MongoDB 5.0, los mensajes del registro de operaciones lentas incluyen un campo remote que especifica la dirección IP del cliente.

remoteOpWaitMillis Campo de registro

A partir de MongoDB 5.0, puedes utilizar el campo de registro remoteOpWaitMillis para obtener el tiempo de espera de los resultados de las particiones.

resolvedViews Campo de registro para consultas lentas en vistas

A partir de MongoDB 5.0, los mensajes de registro para consultas lentas en vistas incluyen un campo resolvedViews que contiene los detalles de la vista.

Definir variables usando la opción let

A partir de MongoDB 5.0, los siguientes comandos tienen una opción de let para definir una lista de variables. Esto permite mejorar la claridad del comando separando las variables del texto de la query.

El comando update también tiene un campo c para definir una lista de variables.

Soporte para el mapeo de nombre de usuario a LDAP nombre distinguido por defecto

A partir de MongoDB 5.0, la opción de archivo de configuración userToDNMapping y la opción de línea de comandos --ldapUserToDNMapping para mongod / mongos y mongoldap ahora asignan el nombre de usuario autenticado como el nombre distinguido de LDAP por defecto si se especifica un documento de mapeo vacío (es decir, un string vacío o un arreglo vacío) a la opción. Anteriormente, proporcionar un documento de mapeo vacío causaría que la mapeo fallara.

dbStats Estadísticas adicionales de espacio libre

A partir de MongoDB 5.0, el comando dbStats produce las siguientes estadísticas adicionales:

serverStatus Cambio de salida

serverStatus incluye los siguientes campos nuevos en su resultado:

Métricas de agregación
Métricas de versión de API
Métricas de replicación
readConcernCounters
Contadores de nivel de confirmación de escritura (write concern)

  • opWriteConcernCounters ahora tiene los siguientes campos nuevos:

    • opWriteConcernCounters.insert.noneInfo

    • opWriteConcernCounters.update.noneInfo

    • opWriteConcernCounters.delete.noneInfo

Número de conexiones roscadas

  • connections.threadedque informa la cantidad de conexiones entrantes de clientes que están asignadas a hilos que atienden las solicitudes de los clientes

Estadísticas de refragmentación
Métricas del ejecutor de servicio

  • network.serviceExecutorsque informa sobre los ejecutores de servicios que ejecutan operaciones por las solicitudes del cliente

Métricas del cursor
Mostrador de seguridad
repl

  • repl ahora incluye un documento primaryOnlyServices que contiene información adicional sobre los servicios que solo se ejecutan en instancias principales de conjuntos de réplicas.

Límite de tamaño de la información de depuración del caché de planes

A partir de MongoDB 5.0, la memoria caché de planes guardará entradas completas de plan cache solo si el tamaño acumulado de plan caches para todas las colecciones es inferior a 0.5 GB. Cuando el tamaño acumulado del plan caches de todas las colecciones supera este umbral, se almacenan entradas adicionales de plan cache sin cierta información de depuración.

El tamaño estimado en bytes de una entrada de plan cache está disponible en el resultado de $planCacheStats.

Cierre de cursores inactivos abiertos dentro de una sesión

A partir de MongoDB 5.0, los cursores creados dentro de una sesión de cliente se cierran cuando la correspondiente sesión de servidor termina con el comando killSessions, si la sesión caduca o si el cliente ha agotado el cursor. Consulta Iterar un cursor en mongosh.

Nuevo validateDBMetadata Comando

MongoDB 5.0 añade el comando validateDBMetadata. El comando validateDBMetadata comprueba que los metadatos almacenados de una base de datos o colección sean válidos en una versión determinada de la API.

Consideraciones sobre el rendimiento

Nivel de confirmación de escritura por defecto implícito

MongoDB 5.0 cambia el nivel de confirmación de escritura (write concern) por defecto a { w: "majority" }. La nueva configuración por defecto de nivel de confirmación de escritura (write concern) podría afectar el rendimiento, ya que MongoDB solo reconoce las escrituras después de que una mayoría calculada de los miembros del conjunto de réplicas hayan ejecutado y guardado la escritura en disco.

Si tu aplicación depende de escrituras sensibles al rendimiento, puedes anular la configuración del nivel de confirmación de escritura (write concern) por defecto a costo de las garantías de durabilidad de los datos. Para anular esta configuración, usted puede:

  • Establece el nivel de confirmación de escritura (write concern) al nivel de operación individual para guardados críticos de rendimiento. Para obtener más información, consulte su documentación del controlador.

  • Utiliza el comando setDefaultRWConcern para establecer explícitamente el nivel de confirmación de escritura (write concern) por defecto.

Advertencia

Si las operaciones de escritura utilizan el nivel { w: 1 } de confirmación de escritura (write concern), el directorio de rollback puede excluir las escrituras enviadas después de un oplog hole si el nodo primario se reinicia antes de que se complete la operación de escritura.

local Nivel de consistencia de lectura por defecto

A partir de MongoDB 5.0, "local" es el nivel de consistencia de lectura por defecto para las operaciones de lectura en el primario y los secundarios. En MongoDB 4.4, las consultas dirigidas a secundarios de clúster particionado utilizan el nivel de consistencia de lectura "available" y pueden devolver documentos huérfanos.

Esto puede introducir un aumento significativo de latencia para las queries de conteo que usan un filtro y para queries cubiertas.

Puedes excluirte de este comportamiento configurando el nivel de consistencia de lectura a nivel de clúster con setDefaultRWConcern.

Retención del historial de snapshot

MongoDB 5.0 aumenta el valor por defecto de minSnapshotHistoryWindowInSeconds a 300, lo que podría tener un impacto negativo en el rendimiento. Si no está usando el nivel de consistencia de lectura "snapshot", puede reducir el valor del parámetro minSnapshotHistoryWindowInSeconds a 5 en todas las instancias mongod. Para obtener más información, consulta Retención del historial de snapshot.

Nota

Si ejecutas un clúster fragmentado, no cambies minSnapshotHistoryWindowInSeconds en servidores de configuración.

Soporte de plataforma

Microarquitectura mínima

MongoDB 5.0 introduce los siguientes requisitos mínimos de microarquitectura:

CPU
Microarquitectura mínima compatible

Intel x86_64

MongoDB 5.0 requiere uno de los siguientes:

  • procesador Intel Core Sandy Bridge o posterior, o

  • Procesador Intel Tiger Lake o posterior Celeron o Pentium.

AMD x86_64

MongoDB 5.0 requiere AMD Bulldozer o posterior.

ARM arm64

MongoDB 5.0 requiere ARMv8.2-A o posterior.

MongoDB v5.0 no es compatible con x86_64 o arm64 plataformas que no cumplen con estos requisitos mínimos de microarquitectura.

Consulta Compatibilidad con la plataforma x86_64 para obtener más información.

Plataformas eliminadas

MongoDB 5.0 elimina el soporte para las siguientes plataformas:

  • macOS 10.13

  • RHEL 7 / CentOS 7 / Oracle 7 en la arquitectura PPC64LE

  • SLES 12 en la arquitectura s390x

  • Ubuntu 18.04 en las arquitecturas PPC64LE y s390x

Consulte Soporte de plataforma para obtener la lista completa de plataformas y arquitecturas compatibles en MongoDB 5.0.

Cambios que afectan la compatibilidad

Algunos cambios pueden afectar la compatibilidad y pueden requerir acciones por parte del usuario. Para obtener una lista detallada de los cambios de compatibilidad, consulta Cambios de compatibilidad en MongoDB 5.0.

Procedimientos de actualización

Importante

Compatibilidad de características entre versiones

Para actualizar a MongoDB 5.0 desde una implementación 4.4, la implementación 4.4 debe tener featureCompatibilityVersion configurado en 4.4. Para comprobar la versión:

db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )

Para actualizar a MongoDB 5.0, consulta las instrucciones de actualización específicas para tu implementación de MongoDB:

Si se necesita orientación sobre cómo actualizar a 5.0, los servicios profesionales de MongoDB ofrecen soporte para la actualización de versiones principales para ayudar a garantizar una transición sin problemas y sin interrupciones en la aplicación MongoDB.

Consideración de reducción de versión

MongoDB solamente soporta degradaciones de una única versión. No se puede retroceder a una versión que esté varias versiones por detrás de la versión actual.

Por ejemplo, puedes rebajar una implementación de la serie 5.0 a la serie 4.4. Sin embargo, no se admite la conversión adicional de esa implementación de la serie 4.4 a una implementación de la serie 4.2.

Descargar

Para descargar MongoDB 5.0, dirígete al Centro de descargas de MongoDB.

Tip

Problemas conocidos

En la Versión
Problemas
Estado

5.0.0

SERVIDOR-58171: No se puede modificar el parámetro granularity de una colección de series de tiempo después de su creación.

Corregido en 5.0.1

5.0.0

SERVIDOR-58392: Una operación de resharding en curso puede impedir que una operación de copia de seguridad o restauración tenga éxito.

Sin resolver

Informar un problema

Para informar un problema, consulte el repositorio de GitHub de MongoDB a fin de obtener instrucciones sobre cómo presentar un ticket de JIRA para el servidor de MongoDB o uno de los proyectos relacionados.

Volver

Registro de cambios

Next

Cambios de compatibilidad

En esta página