Docs Menu
Docs Home
/
Manual de base de datos
/

Notas de versión de MongoDB 5.0

Nota

MongoDB 5.0 lanzado el 13 de julio de 2021

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

5.0.0 - 5.0.2

5.0.0 - 5.0.2

5.0.0 - 5.0.14 (arquitecturas de sistemas ARM64 o POWER)

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

5.0.0 - 5.0.1

5.0.0 - 5.0.21

5.0.0 - 5.0.10

5.0.0 - 5.0.23

5.0.6 - 5.0.21 (colecciones de series temporales fragmentadas por objetos incrustados en metaField)

5.0.0 - 5.0.24

5.0.0 - 5.0.25

Importante

MongoDB 5.0.32 contiene una corrección para CVE-202514847-.

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

  • SERVIDOR-76631 Almacena el nombre del modelo de CPU en los metadatos de FTDC

  • SERVIDOR-78311 mongos no informa writeConcernError en presencia de writeErrors para el comando de inserción

  • SERVER-86674 La sincronización primaria puede creer que está actualizada cuando no lo está.

  • SERVIDOR-89529 Las escrituras reintentables durante la repartición pueden ejecutarse más de una vez si la migración de fragmentos sigue a la operación de repartición

  • SERVIDOR-94635 Hace que los parámetros de actualización de la sesión sean configurables

  • Todos los problemas de JIRA cerrados en 5.0.31

  • 5.0.31 Registro de cambios

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

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 anterior a 5.0.28, un error en el análisis de consultas de ciertas consultas autorreferenciales complejas $lookup Las subcanalizaciones pueden generar valores literales en expresiones para campos cifrados que se envían al servidor con formato incorrecto.

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

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 5.0.25 a, bajo ciertas configuraciones de y, MongoDB Server puede omitir la validación del certificado de pares, lo que puede provocar que conexiones no confiables tengan --tlsCAFile CAFileé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

  • SERVIDOR-50792 Devuelve errores más útiles cuando no se puede encontrar un índice de clave de fragmento para shardCollection/refineCollectionShardKey

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

  • SERVIDOR-81878 startupRecoveryForRestore puede no funcionar correctamente con la eliminación de recopilación aplicada 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

  • SERVIDOR-60466 Los controladores de soporte envían mensajes firmados $clusterTimes al conjunto de réplicas --shardsvrs antes de ejecutar addShard

  • SERVIDOR- La71627 información de ruta de recopilación en caché actualizada bloqueará gravemente todas las solicitudes de cliente cuando un clúster con 1 millones de fragmentos

  • SERVIDOR- La78813 propagación del punto de confirmación falla indefinidamente con cursores de agotamiento con lastCommitted optime nulo

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

  • WT- Se11051 corrige la comparación de la marca de tiempo duradera de inicio más reciente en la validación de la marca de tiempo agregada

  • Todos los problemas de JIRA cerrados en 5.0.21

  • 5.0.21 Registro de cambios

Problemas corregidos:

Problemas corregidos:

Problemas corregidos:

Problemas corregidos:

Problemas corregidos:

Problemas corregidos:

  • SERVIDOR-69611 Establezca la opción del compilador -ffp-contract=off de forma predeterminada

  • SERVER-69220 refineCollectionShardKey permite alternar los campos de clave de fragmento actuales entre basados ​​en rango y en hash, lo que genera inconsistencia en los datos

  • SERVIDOR-67650 El destinatario de la reorganización puede devolver remainingOperationTimeEstimatedSecs=0 cuando el aplicador de registros de operaciones no se ha puesto al día con el buscador de registros de operaciones

  • SERVIDOR- La68094 re-sharding con _id generado personalizado falla con un error de proyección

  • WT-9870 Se soluciona la actualización de la marca de tiempo fijada cada vez que se actualiza 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

Problemas corregidos:

Problemas corregidos:

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

  • SERVIDOR-61321 Mejora el manejo de valores grandes/NaN para la versión de índice de texto

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

  • SERVIDOR-68628 Reintentar una operación de re-fragmentación fallida después de una conmutación por error primaria puede provocar un bloqueo del servidor o la pérdida de escrituras.

  • SERVIDOR-68522 Evita 5 0 que el binario. se inicie en 4 FCV.4 con un índice TTL mal configurado

  • WT-9500 Se corrige RTS para usar la ventana de tiempo de celda en lugar de las marcas de tiempo de clave/valor de la actualización de HS

  • Todos los problemas de JIRA cerrados en 5.0.11

  • 5.0.11 Registro de cambios

Problemas corregidos:

  • SERVIDOR- Se66418 creó una proyección incorrecta durante el análisis de dependencia debido a la suposición del orden de las cadenas

  • SERVIDOR-65821 Bloqueo durante setFCV cuando hay transacciones preparadas que no han persistido en la decisión de confirmación/aborto

  • SERVIDOR-65131 Deshabilitar la orientación de lecturas oportunistas (excepto lecturas protegidas)

  • SERVIDOR-63971 Cambia el parámetro del servidor al comportamiento predeterminado de lectura de escrituras después de 2la transacción de PC

  • SERVIDOR-66433 Fecha límite de retroportación en espera de que finalice la eliminación del rango superpuesto a5 1 versiones anteriores a la versión.

  • Todos los problemas de JIRA cerrados en 5.0.10

  • 5.0.10 Registro de cambios

Problemas corregidos:

Problemas corregidos:

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

  • SERVIDOR-63387 1 StreamingCursor debe devolver los bloques de respaldo en el orden en que se recuperaron del cursor de respaldo de WiredTiger

  • SERVIDOR-62229 Corrige invariante al aplicar entradas de creación de índice mientras recoveryFromOplogAsStandalone=true

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

  • WT-8924 No verifique la ventana de tiempo del disco si hay una lista de inserción al verificar conflictos en el almacenamiento de filas

  • Todos los problemas de JIRA cerrados en 5.0.8

  • 5.0.8 Registro de cambios

Problemas corregidos:

Problemas corregidos:

Problemas corregidos:

  • SERVIDOR- El61483 coordinador de reorganización no puede recuperar la decisión de abortar en el paso a paso, intenta confirmar la operación como exitosa, lo que genera una inconsistencia en los datos

  • SERVIDOR-59858 Agregar observabilidad para las tareas programadas en el hilo del reactor

  • SERVIDOR-51329 Error inesperado no reintentable al apagar un servidor mongos

  • WT-8163 Considerar más escenarios de desalojo para abandonar la limpieza de los puestos de control

  • WT-7912 Corrige la optimización cercana a la búsqueda de prefijo para manejar escenarios donde el rango de claves se divide entre páginas.

  • Todos los problemas de JIRA cerrados en 5.0.5

  • 5.0.5 Registro de cambios

Problemas corregidos:

Problemas corregidos:

  • SERVIDOR-:57667 Mejorar la velocidad de procesamiento para la canalización de clonación de colecciones de resharding

  • SERVIDOR-:57630 Habilitar SSL_OP_NO_RENEGOTIATION en Ubuntu.18 04 al ejecutarse contra OpenSSL..111

  • WT-:8005 Se corrige un error de preparación de confirmación que podría dejar la entrada del almacén de historial sin resolver

  • WT-:7995 Corrige la visibilidad global para que no pueda ir más allá de la visibilidad del punto de control

  • WT-:7984 Se corrige un error que podría provocar que un punto de control omitiera una página de datos

  • Todos los problemas de JIRA cerrados en 5.0.3

  • 5.0.3 Registro de cambios

Problemas corregidos:

Problemas corregidos:

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

MongoDB 5.0 introduce colecciones de series temporales que almacenan eficientemente secuencias de mediciones a lo largo del tiempo. En comparación con las colecciones normales, almacenar datos de series temporales en colecciones de series temporales mejora la eficiencia de las consultas y reduce el uso de disco para sus datos e índices.

MongoDB 5.0 presenta los siguientes operadores de agregación:

Operador
Descripción

$count (aggregation accumulator) proporciona un recuento de todos los documentos cuando se utiliza en la etapa de canalización existente $group (aggregation) y en la nueva 5.0 $setWindowFields etapa MongoDB.

La $count (aggregation accumulator) etapa $count (aggregation) es distinta de la etapa de canalización.

Incrementa un objeto de fecha en una cantidad específica de unidades de tiempo.

Devuelve la diferencia entre dos fechas.

Disminuye un objeto de fecha en una cantidad específica de unidades de tiempo.

Trunca una fecha.

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

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

Agrega el $sampleRate método para seleccionar de forma probabilística documentos de un pipeline a una tasa determinada.

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

Elimina un campo especificado en un documento. Un alias de elimina campos cuyos nombres contengan puntos $setField (). o empiecen por el signo de dólar$ ().

MongoDB 5.0 introduce la $setWindowFields etapa de canalización, que permite realizar operaciones en un intervalo específico de documentos de una colección, conocido como ventana. La operación devuelve los resultados según el operador de ventana seleccionado.

Por ejemplo, puede utilizar la etapa para $setWindowFields generar:

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

A partir de MongoDB 5.0, los operadores$eq, $lt, $lte, $gty$gtecolocados en un operador$exprpueden usar índices para mejorar el rendimiento.

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

A partir de MongoDB,5.0 el aggregate comando y db.collection.aggregate() el método auxiliar tienen una let opción para especificar una lista de variables que se pueden usar en otras partes del flujo de trabajo de agregación. Esto permite mejorar la legibilidad del comando al separar las variables del texto de la consulta.

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.

A partir de MongoDB 5.0, para una subconsulta no correlacionada en una etapa de pipeline$lookupque contiene una etapa$sample, el operador$sampleRateo el operador$rand, la subconsulta siempre se vuelve a ejecutar si se repite. Anteriormente, dependiendo del tamaño de la salida de la subconsulta, esta se almacenaba en caché o se volvía a ejecutar.

Consulta Realiza una subconsulta no correlacionada con $lookup.

A partir de MongoDB 5.0, el optimizador de consultas transfiere los resultados de una etapa$projecta la etapa$sort. Como resultado, las operaciones $sort pueden requerir menos RAM al usarse con la etapa project y evitar errores Sort exceeded memory limit.

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

Operador
Descripción

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

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

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

A partir de MongoDB 5.0:

A partir de 5.0 MongoDB, las operaciones de eliminación implícitas para colecciones limitadas del conjunto de réplicas son procesadas por el miembro principal y replicadas en los miembros secundarios.

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

A partir de MongoDB,5.0 loseventos de cambio contienen el campo updateDescription.truncatedArrays para registrar truncamientos de matrices.

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 permitía la creación de múltiples índices parciales cuando se usaba el mismo patrón de clave con diferentes partialFilterExpressions.

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

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 verdadera debido a un error.

Cuando se ejecuta en una implementación de MongoDB, db.collection.validate() intenta corregir inconsistencias de metadatos de claves múltiples de implementaciones independientes.

MongoDB 5.0 elimina el geoHaystack índice obsoleto y el geoSearch comando. En su 2lugar, utilice un índice d con o uno de $geoNear los operadores de consulta geoespaciales compatibles.

Actualizar su instancia de MongoDB a 5.0 y configurar featureCompatibilityVersion en 5.0 eliminará cualquier índice geoHaystack preexistente.

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

Si un nodo de un conjunto de réplicas se apaga correctamente o se revierte durante la creación de un índice, el progreso de la creación se guarda en el disco. Al reiniciar el servidor, la creación del índice se reanuda desde la posición guardada.

A partir de MongoDB 5.0, el comandoreIndexy el método de shelldb.collection.reIndex()solo se pueden ejecutar en instancias independientes.

A partir de MongoDB 5.0, se eliminan estos comandos de base de datos y mongo métodos auxiliares de shell:

Comando eliminado
Alternativa

db.collection.ensureIndex()

No disponible

No disponible

No disponible

geoSearch

A partir de MongoDB,5.0 no se permiten lecturas que no sean transacciones en la colección con las siguientes opciones y problemas de config.transactions lectura:

A partir de MongoDB 5.0, se introdujeron el comandohelloy el métododb.hello()como reemplazo del comando isMaster y el método db.isMaster(). La nueva métrica de topologíaconnections.exhaustHelloregistra esto enconnections.

A partir de MongoDB,5.0 mongod y ingresan mongos a un período de inactividad para permitir que cualquier operación de base de datos en curso se complete antes de apagarse.

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.

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 son configurables y se pueden establecer --enableMajorityReadConcern en false para evitar que la presión de la memoria caché de almacenamiento inmovilice una implementación con una arquitectura de árbitro primario-secundario (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).

A partir de MongoDB,5.0 puede usar el nuevo replWriterMinThreadCount parámetro de servidor para permitir el cierre de los subprocesos inactivos que superen este mínimo. Si replWriterMinThreadCount se configura con un valor inferior a, se replWriterThreadCount replWriterMinThreadCount agota el tiempo de espera de los subprocesos inactivos superiores a.

Al reconfigurar conjuntos de réplicas de árbitro primario-secundario (PSA) o cambiar a una arquitectura PSA, ahora es necesario, en algunos casos, realizar la reconfiguración en dos pasos. MongoDB 5.0 introduce el método, que realiza ambos pasos. Si no puede usar el método auxiliar, siga el procedimiento descrito en "Modificar un conjunto de rs.reconfigForPSASet() réplicas PSA autoadministrado deforma segura".

maxNumSyncSourceChangesPerHour Determina cuántos cambios de fuente de sincronización pueden ocurrir por hora antes de que el nodo deje de reevaluar temporalmente una fuente de sincronización. Este parámetro no impedirá que un nodo inicie la sincronización desde otro si no tiene una fuente de sincronización.

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.

A partir de MongoDB,5.0 ahora puede rotar los siguientes certificados TLS a pedido sin necesidad de detener primero su instancia mongod o mongos en ejecución:

Para rotar estos certificados, reemplace los archivos de certificado en su sistema de archivos con versiones actualizadas, luego use el rotateCertificates comando o el db.rotateCertificates() método de shell para activar la rotación del certificado.

Rotar certificados de esta manera no requiere tiempo de inactividad y no interrumpe ninguna conexión remota activa.

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

MongoDB 5.0 introduce el opensslCipherSuiteConfig parámetro para habilitar la configuración de los conjuntos de cifrado admitidos que OpenSSL debería permitir al utilizar el 1.3 cifrado TLS.

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.

MongoDB 5.0 introduce la applyOps acción de privilegio que es heredada dbAdminAnyDatabase por.

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

La clave de fragmento ideal permite a MongoDB distribuir los documentos uniformemente en todo el clúster, a la vez que facilita patrones de consulta comunes. Una clave de fragmento deficiente puede provocar problemas de rendimiento o escalabilidad debido a una distribución desigual de los datos. A partir de MongoDB,5.0 puede usar el reshardCollection comando para cambiar la clave de fragmento de una colección y así modificar la distribución de sus datos en el clúster.

A partir de MongoDB,5.0 la $currentOp etapa de agregación (y el comando currentOp db.currentOp() y ​​el método de shell) incluyen información adicional sobre el estado de las operaciones de re-fragmentación en curso para el coordinador de re-fragmentación y los fragmentos donante y receptor.

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

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

A partir de MongoDB,5.0 puede utilizar el comando para cambiar el nombre de una colección renameCollection fragmentada.

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.

A partir de MongoDB,5.0 al usar el movePrimary comando para eliminar un fragmento de un clúster fragmentado, las escrituras en el fragmento original generarán un mensaje de error.

A partir de MongoDB,5.0 los documentos de la colección config.changelog para operaciones de división y fusión contienen un owningShard campo. El owningShard campo muestra el shardId del fragmento que contiene los fragmentos divididos o fusionados.

El campo owningShard ayuda a identificar fragmentos en los que frecuentemente ocurren operaciones de división o fusión.

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

Este parámetro puede afectar el comportamiento de:

El mongo shell ha quedado obsoleto en MongoDB5.0 v. El shell de reemplazo es.mongosh El mongo shell heredado se eliminará en una próxima versión.

El empaquetado de shell también cambia en MongoDB v.5.0 Consulte las instrucciones de instalación para obtener más detalles.

A partir de MongoDB,5.0 Google Cloud Platform KMS y Azure Key Vault son compatibles tanto con mongosh como con el mongo shell heredado como proveedores de servicios de administración de claves (KMS) para el cifrado a nivel de campo del lado del cliente.

Al utilizar un KMS, puede almacenar de forma central y segura las claves maestras del cliente (CMK), que se utilizan para cifrar y descifrar claves de cifrado de datos como parte del flujo de trabajo de cifrado a nivel de campo del lado del cliente.

Además, un KMS configurado permite el uso de campos de datos cuando se utiliza con MongoDB Enterprise.

Para obtener más información,consulte Configurar un proveedor KMS usando mongosh.

A partir de MongoDB,5.0 la preocupación de lectura es compatible con algunas operaciones de lectura fuera de las transacciones multidocumento "snapshot" en los documentos primarios y secundarios. Consulte "Realizar consultas de instantáneas de larga duración".

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

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 predeterminado de true. En MongoDB 6.0 y 5.0.10, el valor predeterminado cambia a false.

Cuando coordinateCommitReturnImmediatelyAfterPersistingDecision falsees, el coordinador de transacciones de fragmentos espera a que todos los miembros reconozcan una confirmación de transacción de múltiples documentos antes de devolver la decisión de confirmación al cliente.

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.

MongoDB 5.0 agrega estadísticas del plan $lookup de ejecución para consultas que utilizan una etapa de canalización.

MongoDB 5.0 añade compatibilidad mejorada con nombres de campo con el$ prefijo () o que contienen. caracteres (). Se han actualizado las reglas de validación para almacenar datos para facilitar el trabajo con fuentes de datos que utilizan estos caracteres.

A partir de MongoDB,5.0 una vez que se configura la preocupación de escritura en todo el clúster (CWWC) a través del setDefaultRWConcern comando, la preocupación de escritura no se puede desconfigurar.

A partir de MongoDB,5.0 la preocupación de escritura predeterminada implícita es. Sin embargo, existe un caso extremo para las implementaciones w: majority de conjuntos 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.

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.

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

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.

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

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

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

A partir de MongoDB,5.0 validate y validan los documentos de una db.collection.validate() colección. Los comandos informan si se infringe alguna regla de validación del esquema.

A partir de MongoDB,5.0 la --repair opción para valida las colecciones para detectar inconsistencias y las corrige si es mongod --repair posible, lo que evita la reconstrucción de los índices. Consulte la opción para conocer su uso y limitaciones.

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

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

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

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

Consulte:

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

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.

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

A partir de MongoDB,5.0 puede utilizar el campo de registro remoteOpWaitMillis para obtener el tiempo de espera de los resultados de los fragmentos.

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

A partir de MongoDB 5.0, los siguientes comandos tienen una opción let para definir una lista de variables. Esto permite mejorar la legibilidad de los comandos al separar las variables del texto de la consulta.

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

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.

A partir de MongoDB,5.0 el comando genera estas estadísticas dbStats adicionales:

serverStatus incluye los siguientes campos nuevos en su resultado:

Métricas de agregación
Métricas de la versión de la API
Métricas de replicación
Leer los contadores de preocupaciones
Escribe Contadores de Preocupaciones
  • opWriteConcernCounters Ahora tiene los siguientes campos nuevos:

    • opWriteConcernCounters.insert.noneInfo

    • opWriteConcernCounters.update.noneInfo

    • opWriteConcernCounters.delete.noneInfo

Número de conexiones roscadas
  • connections.threaded, que informa la cantidad de conexiones entrantes de clientes que están asignados a subprocesos que atienden solicitudes de clientes

Estadísticas de refragmentación
Métricas del ejecutor de servicios
  • network.serviceExecutors, que informa sobre los ejecutores de servicios que ejecutan operaciones para solicitudes de clientes

Métricas del cursor
Mostrador de seguridad
Reemplazar
  • repl ahora incluye un documento que contiene información adicional sobre los servicios que solo se ejecutan en servidores primarios del conjunto de primaryOnlyServices réplicas.

A partir de MongoDB,5.0 la caché del plan guardará plan cache entradas completas solo si el tamaño acumulado de plan caches para todas las colecciones es inferior a 0.5 GB. Cuando el tamaño acumulado de plan caches para todas las colecciones supera este umbral,plan cache se almacenan entradas adicionales 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.

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.

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

MongoDB 5.0 cambia la preocupación de escritura predeterminada { w: "majority" }a. Esta nueva preocupación de escritura predeterminada podría afectar el rendimiento, ya que MongoDB reconoce las escrituras solo después de que una mayoría calculada de miembros del conjunto de réplicas las haya ejecutado y persistido en el disco.

Si su aplicación depende de escrituras que afectan al rendimiento, puede anular la configuración de escritura predeterminada, a costa de las garantías de durabilidad de los datos. Para anular esta configuración, 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.

  • Utilice el comando para establecer explícitamente la preocupación de escritura setDefaultRWConcern predeterminada.

Advertencia

Si las operaciones de escritura utilizan { w: 1 } la preocupación de escritura, el directorio de reversión puede excluir escrituras enviadas después de un agujero de registro de operaciones si el servidor principal se reinicia antes de que se complete la operación de escritura.

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.

Puede optar por no realizar este comportamiento configurando la preocupación de lectura setDefaultRWConcernde todo el clúster con.

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 está ejecutando un clúster fragmentado, no cambie minSnapshotHistoryWindowInSeconds en los servidores de configuración.

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

CPU
Microarquitectura mínima soportada

Intel x86_64

MongoDB 5.0 requiere uno de los siguientes:

  • Procesador Intel Sandy Bridge o posterior Core, 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 las plataformas x86_64 o arm64 que no cumplen estos requisitos mínimos de microarquitectura.

Consulte Compatibilidad de la plataforma x86_64 para obtener más información.

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 Compatibilidad de plataforma para obtener la lista completa de plataformas y arquitecturas compatibles con MongoDB.5.0

Algunos cambios pueden afectar la compatibilidad y requerir la intervención del usuario. Para obtener una lista detallada de los cambios de compatibilidad, consulte Cambios de compatibilidad en MongoDB.5.0

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 verificar la versión:

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

Para actualizar a MongoDB 5.0, se debe consultar las instrucciones de actualización específicas para la 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.

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, puede degradar una implementación de la serie 5.0a una de la serie 4.4. Sin embargo, no se admite degradar esa implementación de la serie 4.4a una de la serie 4.2.

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

Tip

En versión
Cuestiones
Estado

5.0.0

SERVIDOR-: El parámetro de58171 una colección de series temporales granularity no se puede modificar una vez creada la colección.

Arreglado en 5.0.1

5.0.0

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

Irresoluto

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