Cambios de Compatibilidad en MongoDB 6.0

allowDiskUse Cambios

A partir de MongoDB 6.0, las etapas de la canalización que requieren más de 100 megabytes de memoria para ejecutarse escriben archivos temporales en el disco de forma predeterminada. Estos archivos temporales duran mientras se ejecuta la canalización y pueden afectar el espacio de almacenamiento de la instancia. En versiones anteriores de MongoDB, se debía pasar { allowDiskUse: true } a los comandos find y aggregate para habilitar este comportamiento.

Los comandos individuales find y aggregate pueden anular el parámetro allowDiskUseByDefault de las siguientes maneras:

• Se utiliza { allowDiskUse: true } para permitir la escritura de archivos temporales en el disco cuando allowDiskUseByDefault se establece en false

• Se utiliza { allowDiskUse: false } para prohibir la escritura de archivos temporales en el disco cuando allowDiskUseByDefault esté configurado en true

$$SEARCH_META Limitaciones

A partir de MongoDB 6.0, la variable de agregación Atlas Search $$SEARCH_META puede utilizarse en cualquier parte después de una etapa $search en cualquier pipeline, pero no puede utilizarse después de la etapa $lookup o $unionWith en ningún pipeline. La variable de agregación $$SEARCH_META no se puede utilizar en ninguna etapa posterior después de una etapa $searchMeta.

Documentos huérfanos

A partir de MongoDB 5.3, durante la migración de rango, los eventos de flujo de cambios no se generan para las actualizaciones de documentos huérfanos.

Tokens de reanudación

A partir de MongoDB 6.0.9, los tokens de reanudación creados por las pipelines de flujos de cambios con la nueva etapa $changeStreamSplitLargeEvent son incompatibles con MongoDB 5.0. Para obtener más información sobre los tokens de reanudación, consulte Tokens de reanudación.

Filtros

A partir de MongoDB 6.0, siempre que sea posible, los filtros de coincidencia se aplican a los flujos de datos antes que en las versiones anteriores. Esto mejora el rendimiento. Sin embargo, cuando un filtro está definido de forma estricta, una coincidencia anterior puede provocar que una operación que tenía éxito en versiones previas falle en la 6.0.

La última clave de partición restante no se puede descartar inadvertidamente

A partir de MongoDB 6.0, pasar "*" a dropIndexes o db.collection.dropIndexes() elimina todos los índices excepto el índice _id y el último índice de clave de partición restante, si existe. Los intentos de descartar explícitamente el último índice clave de partición restante generan un error.

Los índices existentes se pueden eliminar durante la creación de un índice

A partir de MongoDB 5.2, puedes utilizar dropIndexes o db.collection.dropIndexes() para descartar índices existentes en la misma colección incluso si hay una creación de índices en progreso. En versiones anteriores, intentar descartar un índice diferente durante una creación de índices en curso da como resultado un error BackgroundOperationInProgressForNamespace.

Claves de índices de documentos 2dsphere

Para evitar errores de falta de memoria, indexMaxNumGeneratedKeysPerDocument limita el número máximo de claves de índice 2dsphere generadas para un solo documento.

Consulte indexMaxNumGeneratedKeysPerDocument.

Formato de clave de índice

A partir de MongoDB 6.0, se introdujo un cambio en el formato de clave de índice único. Si crea un índice único en MongoDB 6.0, este no funcionará con versiones de MongoDB anteriores a la 5.3.2 o la 5.0.7.

Community Edition

• RHEL-72-s390x

$regex Las queries de búsqueda ya no ignoran regex no válidas

A partir de MongoDB 5.1, las opciones $regex options inválidas ya no se ignoran. Este cambio hace que $regex options sea más coherente con el uso de $regex en el comando aggregate y las queries de proyección.

$regex Comportamiento ante errores de validación de esquemas

A partir de MongoDB 5.1, si una colección tiene reglas de validación de esquema que contienen no $regex options válidos, el servidor:

• Evita todas las operaciones de inserción y actualización hasta que las reglas de validación del esquema que contienen el patrón de expresión regular no válido se modifiquen con el collMod comando.

• Guarda un error de advertencia en la mongod entrada de registro.

Afirmar que el nivel de confirmación de escritura (write concern) en todo el clúster está configurado al iniciar o agregar una partición

A partir de MongoDB 5.1, al iniciar, reiniciar o añadir un servidor de particiones con sh.addShard() se debe establecer el nivel de confirmación de escritura (write concern) a nivel de clúster (CWWC).

Si el CWWC no está establecido y el fragmento está configurado de tal manera que el nivel de confirmación de escritura por defecto es { w : 1 }, el servidor de fragmentos no se iniciará o no se añadirá y devolverá un error.

Consulta los cálculos del nivel de confirmación de escritura (write concern) por defecto para obtener más información sobre cómo se calcula el nivel de confirmación de escritura por defecto.

rs.reconfig Validación del nivel de confirmación de escritura (write concern) en todo el clúster

A partir de MongoDB 5.1, debe configurar el nivel de cumplimiento de escritura ampliamente específico del Clúster (CWWC) antes de emitir cualquier reconfigs que de otro modo modificaría el nivel de confirmación de escritura (write concern) por defecto del nuevo set de réplicas.

Autenticación intra-clúster

A partir de MongoDB 5.3, SCRAM-SHA-1 no se puede usar para la autenticación intraclúster. Solo se admite SCRAM-SHA-256.

En versiones anteriores de MongoDB, se pueden usar tanto SCRAM-SHA-1 como SCRAM-SHA-256 para la autenticación intra-clúster, incluso si SCRAM no está explícitamente habilitado.

El modo FIPS configura la autenticación SCRAM-SHA-1 por defecto en apagado.

A partir de MongoDB 5.1, las instancias que se ejecutan en modo FIPS tienen el mecanismo de autenticación SCRAM-SHA-1 deshabilitado por defecto. Puedes habilitar el mecanismo de autenticación SCRAM-SHA-1 con el setParameter.mecanismosDeAutenticación comando.

Este cambio no afectará a los controladores destinados a MongoDB setFeatureCompatibilityVersion 4.0+.

OCSP debe estar habilitado

A partir de MongoDB 6.0, si ocspEnabled se configura en true durante la sincronización inicial, todos los nodos deben poder alcanzar el respondedor OCSP.

Si un nodo falla en el estado STARTUP2, establezca tlsOCSPVerifyTimeoutSecs en un valor inferior a 5.

Índices secundarios en colecciones de series temporales

Si hay índices secundarios en colecciones de series de tiempo y necesitas degradar la versión de compatibilidad de funciones (FCV), primero debes descartar cualquier índice secundario que sea incompatible con la FCV degradada. Para obtener más información, consulta setFeatureCompatibilityVersion.

Obsolescencias

$mod Comportamiento de error

A partir de MongoDB 5.1 (y 5.0.4), el operador $mod retorna un error si los valores divisor o remainder evalúan a ciertos valores. Vea el comportamiento del $mod.

Códigos de operación heredados eliminados

MongoDB 6.0 remueve la compatibilidad con los siguientes códigos operativos y comandos de bases de datos heredados:

• OP_INSERT

• OP_DELETE

• OP_UPDATE

• OP_KILL_CURSORS

• OP_OBTENER_MÁS

• OP_QUERY

• getLastError

Si intenta conectarse a una instancia de MongoDB 3.4 o anterior mongod con un shell de MongoDB 5.1 o posterior mongo, recibirá un mensaje de error como el siguiente:

Connection handshake failed. Is your mongod 3.4 or older?
:: caused by :: network error while attempting to run command
'isMaster' on host '127.0.0.1:27017'

Se eliminaron funciones de matriz y cadena obsoletas para JavaScript del lado del servidor

MongoDB 6.0 actualiza el motor interno de JavaScript utilizado para JavaScript del lado del servidor, $accumulator, $function y $where expresiones, y de MozJS-60 a MozJS-91. Se eliminan varias funciones obsoletas y no estándar de arrays y cadenas que existían en MozJS-60 en MozJS-91.

Para obtener la lista completa de las funciones eliminadas de arreglos y string, consulta las siguientes secciones de esta página.

Configuración por defecto de db.stats()

A partir de MongoDB 6.0, el comando dbStats y el método db.stats() solo informan del espacio libre asignado a colecciones si el parámetro freeStorage está establecido en 1.

Intercalaciones y filtros de índices

A partir de MongoDB 6.0, un filtro de índice utiliza la intercalación establecida previamente mediante el comando planCacheSetFilter.

Matrices en colecciones y vistas con distinct el comando

A partir de MongoDB 6.0, el comando distinct devuelve los mismos resultados para colecciones y vistas al utilizar arreglos.

Consulte Matrices en colecciones y vistas.

Colecciones con índice clusterizado

A partir de MongoDB 5.3, si se utilizan colecciones con índice clusterizado, se debe descartar esas colecciones antes de poder degradar a una versión anterior de MongoDB.

Bloqueo de guardado de usuario

A partir de MongoDB 6.0, si necesita degradar la compatibilidad de características entre versiones, asegúrate de deshabilitar la replicación de clúster a clúster y el bloqueo de escritura de usuarios.

Consulta Sincronización entre clústeres y bloqueo de escritura de usuario.

Colecciones de series de tiempo

Se deben descartar las colecciones de series de tiempo antes de realizar una degradación:

• MongoDB 6.0 o posterior a MongoDB 5.0.7 o anterior.

• MongoDB 5.3 a MongoDB 5.0.5 o versiones anteriores.

See colección de series de tiempo.

Cluster Parameters

A partir de MongoDB 6.0, asegúrate de que todas las operaciones de setClusterParameter hayan finalizado. La degradación de compatibilidad de características entre versiones no puede realizarse correctamente si hay operaciones setClusterParameter en curso en clústeres particionados.

Datos de la política SELinux

A partir de MongoDB 5.1, debe ejecutar el siguiente comando desde el directorio en el que se clonó previamente la política SELinux antes de poder revertir a una versión anterior de MongoDB:

sudo make uninstall

Consulte:

• Configurar el directorio de datos de las políticas de SELinux

• Configura el directorio de datos de políticas de SELinux Enterprise

Configuración del Protocolo de interoperabilidad de administración de claves (KMIP)

A partir de MongoDB 6.0, la versión por defecto del protocolo KMIP es 1.2. Para usar la versión KMIP 1.0 o 1.1, utiliza la configuración useLegacyProtocol.

A partir de MongoDB 5.3 Enterprise, si utiliza las siguientes configuraciones de KMIP, debe eliminarlas del archivo de configuración antes de poder actualizar a una versión anterior de MongoDB:

• security.kmip.keyStatePollingSeconds

• security.kmip.activateKeys

Retención basada en el tiempo de Change Streams Colecciones de imágenes previas y posteriores

A partir de MongoDB 6.0, si está utilizando changeStreamOptions.preAndPostImages.expireAfterSeconds para controlar la retención basada en el tiempo de las colecciones de preimagen y postimagen de change streams, debe asegurarse de que no haya operaciones activas de setClusterParameter durante la reducción de versión.

Configuraciones de cifrado del registro de auditoría

A partir de MongoDB 6.0 Enterprise, si utiliza el cifrado del registro de auditoría, debe eliminar las siguientes configuraciones del archivo de configuración antes de poder actualizar a una versión anterior de MongoDB:

• auditLog.auditEncryptionKeyIdentifier

• auditLog.localAuditKeyFile

Los registros de auditoría cifrados existentes permanecen cifrados, y puedes mantener cualquier procedimiento que hayas desarrollado para el almacenamiento y procesamiento de registros cifrados.

Consulta Registro de auditoría.

Change Streams con imágenes previas y posteriores de los documentos

A partir de MongoDB 6.0, si utilizas imágenes previas y posteriores de documentos para los flujos de cambios, debes deshabilitar changeStreamPreAndPostImages para cada colección mediante el comando collMod antes de poder volver a una versión anterior de MongoDB.

Transmisiones de cambio con eventos ampliados

Si la aplicación utiliza flujos de cambios, asegúrate de que no requiera la opción showExpandedEvents, que ya no estará disponible después de una degradación.

LDAP con srv: y srv_raw:

Si la configuración de tu clúster utiliza los nuevos tipos de URLs "srv:" o "srv_raw:" en su configuración de LDAP, no podrá reiniciarse después de un downgrade. Elimina los nuevos tipos de URL de la configuración del clúster antes de realizar la reversión de versión.

colecciones con campos cifrados

Debe descartar las colecciones que utilizan campos cifrados antes de poder completar la degradación de FCV. La degradación no se completará si hay colecciones que utilizan encryptedFields.