Los siguientes cambios de la versión 5.0 pueden afectar la compatibilidad con versiones anteriores de MongoDB.
Ciertos comandos sólo aceptan parámetros reconocidos
A partir de MongoDB 5.0, ciertos comandos de base de datos generan un error si se pasa un parámetro que no ha sido explícitamente aceptado por el comando. En MongoDB 4.4 y versiones anteriores, los parámetros no reconocidos se ignoran de forma silenciosa.
Comandos afectados:
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 |
|---|---|
| |
| |
| |
No disponible | |
| Uno de los operadores del query geoespacial |
| |
| No disponible |
| |
| |
No disponible | |
No disponible |
Parámetros eliminados
MongoDB 5.0 elimina los siguientes parámetros del servidor:
Parámetros eliminados | Descripción |
|---|---|
| MongoDB 5.0 elimina el parámetro de servidor |
| MongoDB 5.0 elimina el parámetro de servidor |
| MongoDB 5.0 elimina el parámetro de servidor |
| MongoDB 5.0 elimina el parámetro de servidor |
| MongoDB 5.0 elimina el parámetro de servidor |
Tipos de índices eliminados
MongoDB 5.0 remueve el índice geoHaystack obsoleto. Utiliza un índice 2d en su lugar.
Actualizar su instancia de MongoDB a 5.0 y configurar featureCompatibilityVersion en 5.0 eliminará cualquier índice geoHaystack preexistente.
Métricas eliminadas
A partir de MongoDB 5.0, el comando serverStatus no produce opReadConcernCounters, que contenía el nivel de consistencia de lectura especificado por las operaciones de query. En su lugar, el nuevo readConcernCounters reemplaza al opReadConcernCounters y contiene información adicional.
A partir de MongoDB 5.0, el comando serverStatus no muestra cache pressure percentage threshold ni current cache pressure percentage en wiredTiger.snapshot-window-settings.
currentOp Cambio de salida
A partir de MongoDB 5.0, la métrica solo está $currentOp.remainingOperationTimeEstimated presente en el fragmento del destinatario cuando se lleva a cabo una operación de reorganización de fragmentos.
Se eliminó el soporte para Raspberry Pi.
MongoDB 5.0 remueve el soporte para Raspberry Pi. Para ejecutar MongoDB en Raspberry Pi, instala la versión 4.4.
Comportamiento de TTL expireAfterSeconds cuando se establece en NaN
A partir de MongoDB 5.0, los índicesTTL con expireAfterSeconds establecido en experimentan NaN un cambio de comportamiento en comparación con las versiones anteriores.
El cambio de comportamiento afecta a:
actualizaciones directas
sincronización inicial desde versiones anteriores
mongorestorede versiones anteriores
Realizar cualquiera de esas acciones hará que un valor expireAfterSeconds de NaN se trate como un expireAfterSeconds de 0. Como resultado, los documentos pueden caducar inmediatamente.
A partir de MongoDB 5.0.14 (y 6.0.2), el servidor no utilizará índices TTL que tengan expireAfterSeconds configurado en NaN.
Cambios en el shell
El shell mongo se ha quedado obsoleto o deprecated en MongoDB v5.0. La replacement shell es mongosh.
El empaquetado de shell también cambia en MongoDB v5.0. Consulta las instrucciones de instalación para obtener más detalles.
Sets de réplicas
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).
secondaryDelaySecs Parámetro de configuración
A partir de MongoDB 5.0, secondaryDelaySecs reemplaza a slaveDelay. Este cambio no es compatible hacia atrás.
Nombres de host requeridos para DNS de horizonte dividido
Para configurar los nodos de clúster para DNS de horizonte dividido, utilice nombres de host en lugar de direcciones IP.
A partir de MongoDB v5.0, replSetInitiate y replSetReconfig rechazarán las configuraciones que utilicen direcciones IP en lugar de nombres de host.
Utilice disableSplitHorizonIPCheck para modificar los nodos que no se pueden actualizar para usar nombres de host. El parámetro solo se aplica a los comandos de configuración.
mongod y mongos no dependen de disableSplitHorizonIPCheck para la validación al inicio. Las instancias heredadas mongod y mongos que utilizan direcciones IP en lugar de nombres de host pueden iniciarse después de una actualización.
Las instancias configuradas con direcciones IP generan un registro de advertencia para que se usen nombres de host en lugar de direcciones IP.
Lecturas no transaccionales en 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:
"majority"y la opción afterClusterTime está configuradaAl usar un MongoDB driver y un
"majority"dentro de una sesión causalmente coherente
Manuales oplog guardados
A partir de MongoDB 5.0, ya no es posible realizar operaciones de escritura manuales en el oplog en un clúster que se ejecuta como un set de réplicas. Realizar operaciones de escritura en el oplog cuando se ejecuta como una instancia autónoma solo debe hacerse con la orientación del Soporte de MongoDB.
Reconfiguración automática para nuevos miembros de set de réplicas de votación
A partir de MongoDB 5.0, un miembro secundario recién agregado no cuenta como miembro con derecho a voto y no puede ser elegido hasta que haya alcanzado el SECONDARY estado.
Al añadir un nuevo nodo con derecho a votación a un conjunto de réplicas, replSetReconfig añadirá internamente un newlyAdded campo a la configuración del nodo. Los nodos con el newlyAdded campo no se contabilizan para el número actual de nodos con derecho a votación. Al finalizar la sincronización inicial y alcanzar el estado,SECONDARY el newlyAdded campo se elimina automáticamente.
Nota
Las configuraciones que intenten agregar un campo llamado
newlyAddedproducirán un error, incluso si se ejecutan con{ force: true }.Si un nodo existente tiene un campo
newlyAdded, usarrs.reconfig()para cambiar la configuración no eliminará el camponewlyAdded. Se añadirá el camponewlyAddeda la configuración proporcionada por el usuario.replSetGetConfigeliminará cualquier campo denewlyAddedde su salida. Si desea ver cualquier campo denewlyAdded, puede query directamente lalocal.system.replsetcolección.
Se eliminaron los valores personalizables para getLastErrorDefaults
A partir de MongoDB 5.0, no se puede especificar un nivel de confirmación de escritura (write concern) predeterminado con settings.getLastErrorDefaults que no sea el valor predeterminado de { w: 1, wtimeout: 0 } . En su lugar, utilice el comando setDefaultRWConcern para establecer la configuración por defecto de "readConcern" o nivel de confirmación de escritura (write concern) en un set de réplicas o en un clúster fragmentado.
Reconocimiento de guardar de set de réplicas
A partir de MongoDB 5.0, los nodos del set de réplicas en el estado STARTUP2 no participan en mayorías de escritura.
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 |
|
4 | 1 | 5 | 3 |
|
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.
Nivel de consistencia de lectura snapshot sobre colecciones con tamaño fijo
A partir de MongoDB 5.0, no es posible utilizar "snapshot" la preocupación de lectura al leer desde una colección limitada.
local es el 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.
Nuevo tipo de devolución cursor.map()
cursor.map() devolvió un Array en el shell heredado mongo. El tipo de devolución es Cursor en mongosh. Puedes usar .toArray() para convertir los resultados.
Actualizar cambios del operador
A partir de MongoDB 5.0, mongod ya no arroja un error cuando se usan los siguientes operadores de actualización con una expresión de operando vacía ( { } ):
Una actualización vacía no produce cambios y no genera ninguna entrada en el oplog (lo que significa que la operación es una “no-op").
Actualizar el orden de procesamiento de operadores
A partir de MongoDB 5.0, los operadores de actualización procesan los campos de documentos con nombres basados en cadenas en orden lexicográfico. Los campos con nombres numéricos se procesan en orden numérico. Consulta Comportamiento del operador de actualización para obtener más información.
$setWindowFields Fase con transacciones y nivel de preocupación de lecturas de snapshot
En las versiones de MongoDB anteriores a la 5.3, la etapa de la canalización de agregación $setWindowFields no puede utilizarse con transacciones ni con el "snapshot" nivel de consistencia de lectura.
Límites de parámetros del operador de pipeline de agregación
Los siguientes operadores del pipeline de agregación ahora tienen un límite máximo de valor entero de 64 bits.
Si pasa un valor que excede este límite, el pipeline retorna un error de argumento inválido.
listDatabases Cambios de salida
A partir de MongoDB 5.0, la salida del comandolistDatabasesque se ejecuta contra unmongodes más consistente que la salida delistDatabasesque se ejecuta contra unmongos.
La siguiente tabla muestra las diferencias entre los tipos de datos de los campos de salida de listDatabases entre MongoDB 5.0 y versiones anteriores. Sólo se listan los campos que difieren entre la versión 5.0 y las anteriores.
Campo | Tipo en MongoDB 5.0 | Tipo en MongoDB 4.4 y versiones anteriores ( mongod) | Tipo en MongoDB 4.4 y versiones anteriores ( mongos) |
|---|---|---|---|
| entero | doble | entero |
| entero | doble | entero |
| entero | no presente (ver abajo) | entero |
La salida de listDatabases ahora incluye el campo totalSizeMb cuando se ejecuta contra un mongos o un mongod. En MongoDB 4.4 y anteriores, totalSizeMb solo aparece cuando se ejecuta contra mongos. totalSizeMb es la suma de los campos de sizeOnDisk, expresada en megabytes.
Cuando se ejecuta sobre mongos, el campo shards en la salida listDatabases contiene un par campo-valor para cada colección de una partición determinada. Los valores de tamaño en el campo shards se expresan como enteros.
Seguridad
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.
Map-Reduce
A partir de la versión 5.0, MongoDB deja de utilizar la operación map-reduce.
Para obtener ejemplos de alternativas de canalización de agregación a operaciones de map-reduce, consulte Map-Reduce a canalización de agregación yEjemplos de Map-Reduce.
Auditoría
MongoDB 5.0 agrega capacidades de auditoría que se pueden configurar en tiempo de ejecución.
Si auditLog.runtimeConfiguration se establece en true, entonces los archivos de configuración mongod y mongos ya no pueden establecer setParameter.auditAuthorizationSuccess ni configurar filtros de auditoría. Si los archivos de configuración del servidor contienen estos ajustes, el servidor no se iniciará y se registrará un error.
Si auditLog.runtimeConfiguration está establecido en false y hay presente un documento de configuración del filtro de auditoría, se emitirá una advertencia de inicio, pero el servidor no se abortará.
Reducir el riesgo de fragmentos obsoletos en transacciones particionadas
A partir de MongoDB 5.0, si cambias el parámetro transactionLifetimeLimitSeconds, debes cambiar también transactionLifetimeLimitSeconds al mismo valor en todos los miembros del set de réplicas del servidor de configuración. Mantener este valor coherente:
Garantiza que el historial de la tabla de enrutamiento se conserve al menos durante el tiempo límite de vida de las transacciones en los miembros del set de réplicas del fragmento.
Reduce la frecuencia de reintentos de transacciones y, por lo tanto, mejora el rendimiento.
Cambios generales
A partir de MongoDB 5.0:
Si el featureCompatibilityVersion está establecido en
"5.0"o superior, los usuarios ya no podrán escribir directamente en la colección<database>.system.views.El comando
reIndexy el método shelldb.collection.reIndex()solo se pueden ejecutar en instancias autónomas.El número de etapas del pipeline de agregación permitidas en un solo pipeline está limitado a 1000.
Borrar la colección final en una base de datos (o borrar la base de datos misma) cuando
directoryPerDBo--directoryperdbestá habilitado, borra el subdirectorio nuevo vacío de esa base de datos.El
$subtractoperador de agregación convertirá el tipo de dato del resultado si es necesario para representarlo con precisión. Consulte para conocer las conversiones$subtractespecíficas.MongoDB remueve la opción de línea de comandos
--serviceExecutory la correspondiente opción de configuraciónnet.serviceExecutor.No puedes autenticarte como usuarios simultáneos en la misma sesión de cliente si la opción
--apiStrictestá activada. Si intentas autenticarte como un nuevo usuario mientras ya has iniciado sesión como usuario existente y la opción de propiedad--apiStrictestá activada, se generará un mensaje de error una vez por cada intento de autenticación. Si no usas la opción--apiStrict, autenticarte como un nuevo usuario mientras ya has iniciado sesión como uno existente guardará una advertencia en el registro una vez por cada intento de autenticación.La opción de pesos solo se permite para índices
$text.Debe configurar explícitamente la preocupación de escritura predeterminada global antes de intentar reconfigurar un conjunto de réplicas no fragmentadas con una configuración que cambie la preocupación de escritura predeterminada implícita. Para configurar la preocupación de escritura predeterminada global, utilice el
setDefaultRWConcerncomando.Para establecer el
replSetOplogde tamaño enmongosh, utiliza el constructorDouble()con el comandoreplSetResizeOplog.
Obsolescencias
Obsoleto | Descripción |
|---|---|
| El shell heredado |
| Obsoleto desde la versión 4.4.1: En su lugar, utilice |
| Obsoleto desde la versión 4.4.1: En su lugar, utilice |
| Obsoleto en la versión 5.0: en su lugar, use |
| Obsoleto en la versión 5.0: en su lugar, use |
Obsoleto en la versión 5.0: Desconéctese del servidor para finalizar su sesión. | |
Obsoleto en la versión 5.0: Desconéctese del servidor para finalizar su sesión. | |
Campo del mensaje de auditoría local | Obsoleto desde la versión 5.0: Usa el campo |
Códigos de operación obsoletos del protocolo de conexión
MongoDB 5.0 desaprueba los siguientes códigos operativos del protocolo de conexión:
OP_REPLYOP_UPDATEOP_INSERTOP_QUERYOP_GET_MOREOP_DELETEOP_KILL_CURSORS
Las versiones más recientes del driver emplean OP_MSG en lugar de estos códigos de operación obsoletos.
Los comandos y métodos relacionados también están obsoletos en MongoDB 5.0:
getLastErrordb.getLastError()db.getLastErrorObj()
Para garantizar que su driver utilice el protocolo de conexión más actualizado, actualice su driver a una versión compatible con 5.0.
Cualquier código que utilice explícitamente getLastError, db.getLastError() o db.getLastErrorObj() debe usar en su lugar la API CRUD para emitir la escritura con el nivel de confirmación de escritura (write concern) deseado. La información sobre el éxito o el fracaso de la operación de guardar será proporcionada directamente por el driver como un valor de retorno.
Compatibilidad de funcionalidad 5.0
Algunas funcionalidades en 5.0 requieren no solo los binarios de 5.0, sino que la featureCompatibilityVersion (compatibilidad de características entre versiones) esté configurada en 5.0. Estas funcionalidades incluyen:
La creación de colecciones de series de tiempo requiere que la compatibilidad de características entre versiones esté configurada en 5.0o superior.
Configurar la gestión del filtro de auditoría en tiempo de ejecución requiere definir la compatibilidad de características entre versiones en 5.0+
El uso de
.y$en los nombres de campo requiere que compatibilidad de características entre versiones esté establecido en 5.0o superior.Volver a fragmentar una colección requiere que compatibilidad de características entre versiones esté configurado en 5.0+ .