Cambios de compatibilidad en MongoDB 8.0

Las queries para valores nulos no coinciden con campos indefinidos

A partir de MongoDB 8.0, comparaciones con null En las expresiones de coincidencia de igualdad no coinciden con los valores undefined.

Por ejemplo, considera estos documentos y la query:

// create the people collection
db.people.insertMany( [
   { _id: 1, name: null },
   { _id: 2, name: undefined },
   { _id: 3, name: [ "Gabriel", undefined ] },
   { _id: 4, names: [ "Alice", "Charu" ] }
] )

db.people.find( { name: null } )

Antes de MongoDB 8.0, el query anterior coincidiría con documentos donde:

• El campo name es null (_id: 1)

• El campo name es undefined o contiene un elemento de arreglo undefined (_id: 2 y _id: 3)

• El campo name no existe (_id: 4)

A partir de MongoDB 8.0, la query anterior no coincide con documentos en que el campo name es undefined o contiene undefined elementos de arreglo. La query solo coincide con documentos en que:

• El campo name es null o contiene un elemento de arreglo null (_id: 1)

• El campo name no existe (_id: 4)

Este cambio de comportamiento de query también afecta estas operaciones:

• $eq

• $in

• $lookup, porque un campo local null ya no coincide con un campo foráneo undefined.

Para aprender a reescribir tus queries o migrar tus datos para tener en cuenta este cambio de comportamiento, consulta Migrar queries y datos no definidos.

No se puede conectar directamente a la partición y ejecutar comandos

A partir de MongoDB 8.0, solo puedes ejecutar ciertos comandos en nodos de clústeres fragmentados. Si intentas conectarte directamente a un nodo y ejecutar un comando no compatible, MongoDB devuelve un error:

"You are connecting to a sharded cluster improperly by connecting directly
to a shard. Please connect to the cluster via a router (mongos)."

Para ejecutar un comando de base de datos no compatible directamente contra un nodo en un clúster fragmentado, debes conectarte a mongos o tener el rol de solo mantenimiento directShardOperations.

MongoDB admite la transición en línea desde un set de réplicas a un clúster de 1 partición al permitir que los comandos se ejecuten directamente contra una partición. Sin embargo, una vez que el clúster tiene más de una partición, solo los comandos enumerados se pueden ejecutar directamente en el fragmento sin el rol exclusivo de mantenimiento directShardOperations.

Nivel de confirmación de escritura mayoría

A partir de MongoDB 8.0, las operaciones de escritura que utilizan el nivel de confirmación de escritura "majority" devuelven un reconocimiento cuando la mayoría de los nodos del set de réplicas han escrito la entrada del oplog para el cambio. Esto mejora el rendimiento de las operaciones de escritura "majority". En versiones anteriores, estas operaciones esperaban y devolvían una confirmación después de que la mayoría de los nodos del set de réplicas aplicaran el cambio.

Buffers de Oplog

A partir de MongoDB 8.0, los secundarios guardan y aplican entradas de oplog para cada lote en paralelo. Esto introduce un cambio disruptivo para la métrica de estado metrics.repl.buffer, ya que ahora proporciona información sobre dos búferes en lugar de uno.

MongoDB 8.0 desaprueba las siguientes métricas de estado del servidor:

• metrics.repl.buffer.count

• metrics.repl.buffer.maxSizeBytes

• metrics.repl.buffer.sizeBytes

Las reemplaza con estas métricas:

• metrics.repl.buffer.apply.count

• metrics.repl.buffer.apply.maxSizeBytes

• metrics.repl.buffer.apply.sizeBytes

• metrics.repl.buffer.write.count

• metrics.repl.buffer.write.maxSizeBytes

• metrics.repl.buffer.write.sizeBytes

Rendimiento del apagado

A partir de MongoDB 8.0, Bulk.insert() y las cargas de trabajo de ingesta de datos pueden rendir mejor. Sin embargo, el apagado de MongoDB inmediatamente después de ejecutar estas cargas de trabajo podría tardar más debido a que los datos extra se vacían en el disco.

Comandos compactos concurrentes no permitidos

A partir de MongoDB 8.0, si intenta ejecutar varios comandos compact concurrentes en la misma colección, MongoDB devuelve un error.

Validación de entrada geoespacial

A partir de MongoDB 8.0, no se pueden utilizar queries geoespaciales con entradas mal formadas. En versiones anteriores, ciertos queries geoespaciales aceptaban entradas con formato incorrecto sin generar ningún error.

Los proveedores de identidad de OIDC pueden compartir un emisor

A partir de MongoDB 8.0, cuando se definen varios proveedores de identidad (IDP), el parámetro oidcIdentityProviders acepta valores issuer duplicados siempre que el valor audience sea único para cada emisor. También está disponible en las versiones 7.3 y 7.0.

Parámetros eliminados

MongoDB 8.0 remueve el parámetro storeFindAndModifyImagesInSideCollection.

Cambio de salida de serverStatus

A partir de MongoDB 8.0, wiredTiger.concurrentTransactions se renombra a queues.execution.

Colecciones system.buckets con serie de tiempo

Al actualizar a 8.2, si tienes alguna colección system.buckets que no sea de series de tiempo, es posible que necesites drop o rename esas colecciones antes de actualizar, dependiendo de la versión del parche 8.0:

MongoDB 8.0.5 y posterior

No es necesario descartar las colecciones system.buckets que no sean colecciones de serie de tiempo antes de actualizar. Sin embargo, debes descartarlas o renombrarlas después de completar la actualización.

MongoDB 8.0.4 y versiones anteriores

Debe eliminar o renombrar system.buckets las colecciones que no sean de series temporales antes de actualizar. Todas las system.buckets colecciones deben tener configuradas opciones de series temporales válidas antes de actualizar a las versiones -.8.0.0 8.0.4

Para determinar si tienes colecciones system.buckets que no sean colecciones de series de tiempo, usa el método db.getCollectionInfos() con un filtro:

db.getCollectionInfos(
   {
      $and: [
         { name: { $regex: /^system\.buckets/ } },
         { 'options.timeseries': { $exists: false } }
      ]
   }
)

Ordenar por campos no existentes

Al ordenar por campos inexistentes, MongoDB no garantiza un orden de salida específico. El comportamiento en estos casos puede cambiar de una versión a otra.

$rank y $denseRank Comportamiento

A partir de MongoDB 8.0, valores null y valores de campo faltantes en $denseRank y $rank en las operaciones sortBy se tratan de la misma manera al calcular los rankings. Este cambio hace que el comportamiento de denseRank y rank sean coherentes con $sort.

$shardedDataDistribution Salida

A partir de MongoDB 8.0, $shardedDataDistribution solo devuelve resultados para la partición primaria de una colección si la partición primaria tiene fragmentos o documentos huérfanos.

Para obtener más detalles, consulte $shardedDataDistribution.

TCMalloc mejorado

A partir de MongoDB 8.0, MongoDB utiliza una versión mejorada de TCMalloc que utiliza cachés por CPU, en lugar de cachés por hilo, para reducir la fragmentación de la memoria y hacer que la base de datos sea más resistente a cargas de trabajo de alta presión.

Para utilizar el nuevo TCMalloc con un mejor rendimiento, consulta Optimización del rendimiento de TCMalloc para una implementación autogestionada.