Docs Menu
Docs Home
/ /

Cambios de compatibilidad en MongoDB 7.0

Esta página describe los cambios introducidos en MongoDB 7.0 que pueden afectar la compatibilidad con versiones anteriores de MongoDB.

MongoDB 7.0 es una versión principal, lo que significa que es compatible tanto con MongoDB Atlas como con las implementaciones on-premises. MongoDB 7.0 incluye los cambios introducidos en Rapid Releases 6.1, 6.2 y 6.3 de MongoDB. Esta página describe los cambios de compatibilidad introducidos en esas Rapid Releases y MongoDB 7.0.

Para obtener más información sobre las diferencias entre las versiones principales y rápidas, consulte Control de versiones de MongoDB.

Para obtener más información sobre la degradación de MongoDB 7.0, consulta Degradación de 7.0 a 6.0.

Obsoleto
Descripción

storageDetails

Obsoleto en la versión 7.0.

Obsoleto solo para Linux en 7.0.

A partir de MongoDB 7.0, se discontinúa la supervisión gratuita. Los siguientes no están disponibles:

  • cloud.monitoring.free opción de configuración

  • --enableFreeMonitoring server parameter

  • db.enableFreeMonitoring() Comando

  • db.disableFreeMonitoring() Comando

  • setFreeMonitoring Comando

A partir de MongoDB 7.0, Queryable Encryption con queries de igualdad está disponible de forma general (GA). Las mejoras en la GA lo hacen incompatible con la vista previa pública de Queryable Encryption, que no debe usarse ahora que la característica es GA.

Para utilizar Queryable Encryption con queries de igualdad, el servidor de MongoDB debe ser la versión 7.0 o posterior y los controladores deben ser compatibles con la versión 7.0. Si sigues utilizando la vista previa pública de Queryable Encryption incluida en MongoDB 6.x, el servidor debe permanecer en la versión 6.x y los controladores deben ser compatibles con la versión 6.x. No puedes utilizar controladores compatibles con MongoDB 6.x con un servidor 7.0, ni controladores compatibles con 7.0 con un servidor 6.x. Intentar hacerlo resulta en un error.

Para facilitar la actualización, los drivers de MongoDB 7.0 pueden descifrar datos creados con los drivers de MongoDB 6.x. Para las opciones de actualización, consulta las siguientes secciones.

Si es posible, crea nuevas colecciones en lugar de migrar las creadas con la vista previa pública de Queryable Encryption en MongoDB 6.x:

  1. Actualiza el servidor y los controladores de MongoDB a la versión 7.0.

  2. Configura una nueva colección cifrada con un nombre diferente al de la colección anterior.

  3. Inserta nuevos datos o una versión sin cifrar de los datos existentes si dispones de una copia local.

  4. Descarta la colección de la versión 6.x anterior.

Si no puedes utilizar datos nuevos o no tienes una versión no cifrada de los datos existentes:

  1. Actualiza el servidor y los controladores de MongoDB a la versión 7.0

  2. Utilizando un controlador compatible con 7.0, haz un query en la colección cifrada para descifrarla.

  3. Guarda la salida localmente.

  4. Configura una nueva colección cifrada e ingiere los datos.

Advertencia

  • El mongoexport Las mongodump operaciones y no descifran la colección. Debe consultar la colección desde un controlador para obtener los datos descifrados.

  • Los controladores compatibles con MongoDB 7.0 no pueden hacer un query en campos cifrados con datos cifrados con controladores compatibles con MongoDB 6.x. Para descifrar datos, haz un query en un campo no cifrado o en toda la colección.

Las siguientes características de la versión 7.0 no son compatibles con versiones anteriores de MongoDB. Para degradar de MongoDB 7.0 a una versión anterior, debes remover los datos que utilicen cualquiera de las siguientes características:

  • Colecciones con encryptedFields e índices de rango

  • Los índices comodín compuestos requieren la compatibilidad de características entre versiones 7.0 o superior. Un versión anterior a 7.0 mongod no se inicia si se está utilizando uno o más índices comodín compuestos.

  • Configurar los servidores de configuración que tienen colecciones con changeStreamPreAndPostImages activado

  • Índices TTL secundarios con filtros parciales en colecciones de series de tiempo

  • Colecciones de series de tiempo con parámetros de buckets personalizados

A partir de MongoDB 7.0, puedes configurar servidores para autenticar certificados X.509 como miembros del clúster identificados por atributos o valores de extensión. También puedes anular esta configuración para aceptar certificados alternativos durante una actualización progresiva.

Para cambiar a MongoDB 6.0, realiza el procedimiento de rotación de certificados para desactivar la configuración net.tls.clusterAuthX509 y rotar los certificados de membresía de clúster por otros con atributos DC, O y OU coincidentes.

Una vez que esto esté completo, puedes degradar el clúster.

  • Elimina los índices TTL parciales de las colecciones de series de tiempo.

  • Remueve o modifica colecciones utilizando nuevos parámetros de índice. En algunos casos, puedes usar collMod para cambiar a la configuración de granularidad heredada. De lo contrario, deberás descartar la colección antes de realizar una degradación.

Las operaciones de parámetros setClusterParameter activas impiden que la compatibilidad de características entre versiones (FCV) se complete de forma exitosa.

Elimina las colecciones que usan la opción de colección encryptedFields antes de realizar una degradación.

Los índices comodín compuestos requieren la compatibilidad de características entre versiones 7.0 o superior. Un versión anterior a 7.0 mongod no se inicia si se está utilizando uno o más índices comodín compuestos.

A partir de MongoDB 7.0, solo se puede especificar un campo audience oidcIdentityProviders para los tokens de acceso OIDC. Los campos audience con arreglos vacíos o arreglos de varios strings no son válidos.

Para obtener más detalles, consulte Campos oidcIdentityProviders.

Antes de MongoDB 7.0, $natural acepta valores de tipo incorrectos, tales como 0, NaN, "X" y -0.01. Después de MongoDB 7.0, si pasas cualquier valor que no sea 1 y -1 a $natural, MongoDB devuelve un error.

A partir de MongoDB 6.3, puedes configurar la granularidad de los buckets de series de tiempo utilizando los nuevos parámetros de buckets personalizados bucketMaxSpanSeconds y bucketRoundingSeconds. Para degradar a una versión inferior a 6.3, debes descartar todas las colecciones con estos parámetros o modificarlas para utilizar el granularity correspondiente. Para obtener más detalles, consulta collMod.

No todos los valores de bucketMaxSpanSeconds y bucketRoundingSeconds corresponden a un valor de granularity. En tales casos, debes descartar la colección.

A partir de MongoDB 6.3, puedes crear índices parciales de Time To Live (TTL) en colecciones de series de tiempo. Para degradar por debajo de 6.3, debes remover todos los índices parciales de TTL de tus colecciones de series de tiempo.

A partir de MongoDB 6.2, debes establecer value entre 1 y 1024 (inclusive) al insertar o actualizar documentos con el campo _id: chunksize en la colección config.settings. Si especificas un value no válido, MongoDB devuelve un error de validación de esquema.

Cualquier campo value fuera del rango de 1 a 1024 MB (inclusive) establecido antes de MongoDB 6.2 permanece sin cambios.

A partir de la versión 6.2, MongoDB remueve el campo maxSize del comando addShard. Como resultado:

  • Ejecutar addShard con el campo maxSize devuelve un error InvalidOptions.

  • Los nuevos documentos en la colección shards ya no incluyen el campo maxSize.

  • Se ignoran todas las entradas de campo maxSize preexistentes.

A partir de MongoDB 6.1, cuando una expresión $add recibe una lista de entrada con múltiples valores de punto flotante, MongoDB puede devolver resultados ligeramente diferentes en comparación con versiones anteriores.

La expresión $add ya no considera errores de redondeo de punto flotante. Como resultado, $add se comporta como la suma en la mayoría de los lenguajes de programación.

Por ejemplo, la siguiente expresión $add devuelve un resultado diferente cuando se ejecuta en MongoDB 6.1 en comparación con versiones anteriores:

db.test.aggregate(
[
{
$project: {
sumOfValues: {
$add: [ 0.1, 0.2, 0.3 ]
}
}
}
]
)

MongoDB 6.1 y salida posterior:

[
{
_id: ObjectId("6390f8085425651d8d0ef0a7"),
sumOfValues: 0.6000000000000001
}
]

MongoDB 6.0 y salida anterior:

[
{
_id: ObjectId("6390f8085425651d8d0ef0a7"),
sumOfValues: 0.6
}
]

A partir de MongoDB 6.0.3, no se realiza la división automática de fragmentos. Esto se debe a las mejoras en la política de balanceo. Los comandos de división automática aún existen, pero no ejecutan ninguna operación.

A partir de MongoDB 6.1, los siguientes comandos de división automática no realizan ninguna operación:

A partir de MongoDB 6.1, el registro en la bitácora siempre está habilitado. Como resultado, MongoDB remueve la opción storage.journal.enabled y las opciones de línea de comandos --journal y --nojournal correspondientes.

A partir de MongoDB 6.1, SNMP ha sido eliminado. Todas las opciones de línea de comandos relacionadas impiden que mongod se inicie. Para supervisar su implementación, utilice MongoDB Ops Manager.

A partir de MongoDB 6.1, el valor por defecto para coordinateCommitReturnImmediatelyAfterPersistingDecision es false.

currentOp.opStatus se elimina de las métricas de redistribución en MongoDB 6.1.

No se puede crear una vista desde un namespace de colección de buckets con serie de tiempo (es decir, una colección con el prefijo system.buckets).

Si estás actualizando a MongoDB 6.1 desde una versión anterior, debes descartar todas las vistas que se hayan creado en las colecciones system.buckets.

Volver

7.0