Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

setFeatureCompatibilityVersion (comando de base de datos)

setFeatureCompatibilityVersion

Habilitar o deshabilitar las funcionalidades que garantizan la persistencia de datos incompatibles con versiones anteriores de MongoDB. Solo puedes emitir el setFeatureCompatibilityVersion contra la base de datos admin.

Advertencia

La habilitación de características incompatibles con versiones anteriores puede complicar el proceso de degradación, ya que debes Remover cualquier característica incompatible con versiones anteriores que persista antes de realizar la degradación.

Se recomienda que, después de actualizar, se permita que la implementación se ejecute sin habilitar funcionalidades incompatibles con versiones anteriores durante un período de prueba para asegurar que la probabilidad de tener que realizar una degradación sea mínima. Cuando te tenga la certeza de que la probabilidad de degradación es mínima, se deben activar estas funcionalidades.

Este comando está disponible en implementaciones alojadas en los siguientes entornos:

  • MongoDB Enterprise: La versión basada en suscripción y autogestionada de MongoDB

  • MongoDB Community: La versión de MongoDB con código fuente disponible, de uso gratuito y autogestionada.

Cambiado en la versión 8.3.

El comando tiene la siguiente sintaxis:

db.adminCommand(
{
setFeatureCompatibilityVersion: <version>,
confirm: true,
writeConcern: { wtimeout: <timeout> },
dryRun: <boolean>
}
)

El comando setFeatureCompatibilityVersion toma los siguientes campos:

Requerido

Los valores posibles para version son:

Versión
Descripción

"8.3"

Disponible en MongoDB 8.3. Implementaciones

Permite las 8.3 características que persisten datos incompatibles con MongoDB 8.2.

"8.2"

Disponible en MongoDB 8.2 y MongoDB 8.3 Implementaciones

A partir de MongoDB 8.3, puedes realizar un downgrade compatibilidad de características entre versiones de "8.3" a "8.2".

"8.0"

Disponible en MongoDB 8.0. Implementaciones

Permite las 8.0 características que persisten datos incompatibles con MongoDB 7.0.

"7.0"

Disponible en las implementaciones de MongoDB 7.0

Habilita las características de 7.0 que mantienen datos incompatibles con MongoDB 6.0.

Requerido

Nuevo en la versión 7.0.

Establece en true para confirmar el cambio de compatibilidad de características y permitir que la operación continúe.

Si omites el parámetro confirm o estableces confirm en un valor distinto de true, el comando falla y devuelve una advertencia sobre la modificación de la compatibilidad de funcionalidades entre versiones.

Opcional

El writeConcern especifica el valor wtimeout del nivel de confirmación de escritura en milisegundos:

  • El período de tiempo que el primario espera la confirmación de la mayoría de los miembros del Set de réplicas. Si no se recibe el acuse de recibo en el período de tiempo, la operación falla.

  • Por defecto es 60000 milisegundos. Utiliza un período de tiempo más largo si los miembros secundarios del Set de réplicas tienen un retraso que excede el wtimeout por defecto.

Nota

  • Para una instancia autónoma, ejecuta el comando en la instancia mongod autónoma.

  • Para un Set de réplicas, ejecuta el comando en el Primario. La mayoría de los miembros portadores de datos deben estar disponibles.

  • Para un clúster fragmentado, ejecuta el comando en una instancia mongos.

Opcional

Si se establece en true, MongoDB simula una actualización o degradación de la compatibilidad de características entre versiones. Si el clúster contiene datos incompatibles, la operación falla con un error.

Nuevo en la versión 8.3.

Si debes reducir la compatibilidad de características entre versiones por debajo de 8.0, debes ejecutar primero el comando transitionToDedicatedConfigServer. Para obtener detalles sobre la degradación, consulta Degradación de la compatibilidad de características entre versiones.

Si intentas actualizar la compatibilidad de características entre versiones de un clúster que contiene datos incompatibles con versiones anteriores en la versión actualizada, recibirás un error CannotUpgrade. Los datos no compatibles hacia adelante pueden referirse a cualquier dato de tu clúster que dependa de una funcionalidad que fue eliminada en la versión de destino.

Cuando se produce este error, se puede:

  • Modifique los datos de su clúster para eliminar funciones que sean incompatibles con versiones futuras y, a continuación, vuelva a ejecutar el comando setFeatureCompatibilityVersion con la versión actualizada para establecer la compatibilidad de características entre versiones en la versión actualizada.

  • Ejecute el comando setFeatureCompatibilityVersion con la versión original degradada para restablecer la compatibilidad de características entre versiones a la versión original.

    Importante

    Si se establece la compatibilidad de características entre versiones a la versión original, se detiene el procedimiento de actualización y se cambia la compatibilidad de características entre versiones de nuevo a la versión degradada. Este procedimiento no restablece el clúster al estado anterior al inicio de la actualización de compatibilidad de características entre versiones.

    Si la actualización del FCV confirma que no hay datos incompatibles en el futuro pero por lo demás se detiene o falla, cualquier intento posterior de degradación del FCV también fallará con un mensaje de error. Debes completar la actualización de compatibilidad de características entre versiones antes de intentar degradar la compatibilidad de características entre versiones.

Si intentas rebajar la compatibilidad de características entre versiones de un clúster que contiene datos incompatibles con la versión rebajada, recibirás un error CannotDowngrade. Los datos incompatibles con versiones anteriores pueden referirse a cualquier dato en tu clúster que dependa de una funcionalidad que no está disponible en la versión de destino.

Cuando se produce este error, se puede:

  • Se deben modificar los datos del clúster para eliminar las funcionalidades incompatibles con versiones anteriores, luego se debe volver a ejecutar el comando setFeatureCompatibilityVersion con la versión degradada para establecer la compatibilidad de características entre versiones en la versión degradada.

  • Ejecuta el comando setFeatureCompatibilityVersion con la versión mejorada original para restablecer la compatibilidad de características entre versiones a la versión original.

    Importante

    Configurar la compatibilidad de características entre versiones a la versión original detiene el procedimiento de degradación y cambia la compatibilidad de características entre versiones de nuevo a la versión mejorada. Este procedimiento no restablece el clúster al estado anterior a que comenzara la rebaja de compatibilidad de características entre versiones.

    Si la actualización compatibilidad de características entre versiones confirma que no hay datos incompatibles hacia atrás, pero de otro modo se detiene o falla, cualquier intento posterior de actualización de compatibilidad de características entre versiones también fallará con un mensaje de error. Debe completar la degradación de la compatibilidad de características entre versiones antes de intentar actualizar la compatibilidad de características entre versiones.

A partir de 8.3, puedes revertir la compatibilidad de características entre versiones de tu implementación a la versión menor inmediatamente anterior.

Para aprender más, consultar Degradar 8.3 a 8.2.

Ciertas operaciones en segundo plano pueden impedir la ejecución de setFeatureCompatibilityVersion. Utiliza currentOp para identificar cualquier operación en curso.

Si se produce un setFeatureCompatibilityVersion cambio de trigger durante una sincronización inicial, la sincronización puede fallar con un mensaje de error OplogOperationUnsupported al reproducir las entradas en la fase de aplicación oplog. La sincronización después de este intento tiene éxito porque la fase de Operación ya no repite la Operación.

Implementaciones
featureCompatibilityVersion

Para los nuevos 8.3 implementaciones

"8.3"

Para 8.3 implementaciones actualizadas desde 8.2

"8.2" hasta que setFeatureCompatibilityVersion a "8.3".

Para los nuevos 8.0 implementaciones

"8.0"

Para 8.0 implementaciones actualizadas desde 7.0

"7.0" hasta que setFeatureCompatibilityVersion a "8.0".

Para nuevas implementaciones de 7.0

"7.0"

Para implementaciones de 7.0 actualizadas desde 6.0

"6.0" hasta que setFeatureCompatibilityVersion a "7.0".

Este comando debe realizar guardados en una colección interna del sistema. Si por alguna razón el comando no se completa correctamente, puede volver a intentarlo con seguridad, ya que la operación es idempotente.

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.

  1. Si has activado la replicación de clúster a clúster, desactívala.

  2. Si has activado el bloqueo de guardado del usuario, desactívalo:

    db.runCommand( { setUserWriteBlockMode: 1, global: false } )
  3. Espera a que se complete el comando anterior.

  4. Reduce la compatibilidad de características entre versiones usando setFeatureCompatibilityVersion.

Para obtener más información sobre MongoDB Cluster-to-Cluster Sync, consulta la documentación.

Los árbitros no replican la admin.system.version colección. Por esta razón, los árbitros siempre tienen una compatibilidad de características entre versiones igual a la versión de degradación del binario, independientemente del valor de la compatibilidad de características entre versiones del Set de réplicas.

Por ejemplo, un árbitro de un clúster de MongoDB 5.0 tiene un valor de compatibilidad de características entre versiones de 4.4.

Para ver el featureCompatibilityVersion de una instancia de mongod, ejecuta el comando getParameter en una instancia de mongod:

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

La salida es similar a:

{
featureCompatibilityVersion: { version: '5.0' },
ok: 1,
'$clusterTime': {
clusterTime: Timestamp({ t: 1660318752, i: 5 }),
signature: {
hash: Binary(Buffer.from("ce0cff3621e9b089fa6d8e9a1e1efc1a1ff15dab", "hex"), 0),
keyId: Long("7129893797260951557")
}
},
operationTime: Timestamp({ t: 1660318752, i: 5 })
}

Nota

La operación no está definida en las instancias de mongos.

En un clúster particionado que tiene habilitado el control de acceso, debe conectarse al fragmento como usuario local del fragmento para ejecutar el comando.

Para habilitar las 8.0 funcionalidades que persisten datos incompatibles con MongoDB 7.0, configura la compatibilidad de la funcionalidad en "8.0" en la implementación de MongoDB 8.0:

Nota

Ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin.

  • Para una instancia autónoma, ejecuta el comando en la instancia mongod autónoma.

  • Para un Set de réplicas, ejecuta el comando en el Primario. La mayoría de los miembros portadores de datos deben estar disponibles.

  • Para un clúster fragmentado, ejecuta el comando en una instancia mongos.

db.adminCommand(
{
setFeatureCompatibilityVersion: "8.0",
confirm: true
}
)

Para desactivar 8.0 las funcionalidades que persisten datos incompatibles con MongoDB 7.0, establece la compatibilidad funcional a "7.0" en la implementación MongoDB 8.0:

Nota

Ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin.

  • Para una instancia autónoma, ejecuta el comando en la instancia mongod autónoma.

  • Para un Set de réplicas, ejecuta el comando en el Primario. La mayoría de los miembros portadores de datos deben estar disponibles.

  • Para un clúster fragmentado, ejecuta el comando en una instancia mongos.

  • "7.0" featureCompatibilityVersion es compatible con las implementaciones de MongoDB 7.0 y MongoDB 8.0.

db.adminCommand(
{
setFeatureCompatibilityVersion: "7.0",
confirm: true
}
)

Si ejecutas este comando como parte del proceso de degradación de MongoDB 8.0 a MongoDB 7.0, también se deben remover todas las funcionalidades persistentes que sean incompatibles con 7.0. Consulte los procedimientos apropiados de degradación.

Para habilitar las características de 7.0 que persisten datos incompatibles con MongoDB 6.0, establece la compatibilidad de características en "7.0" en la implementación de MongoDB 7.0:

Nota

Ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin.

  • Para una instancia autónoma, ejecuta el comando en la instancia mongod autónoma.

  • Para un Set de réplicas, ejecuta el comando en el Primario. La mayoría de los miembros portadores de datos deben estar disponibles.

  • Para un clúster fragmentado, ejecuta el comando en una instancia mongos.

db.adminCommand(
{
setFeatureCompatibilityVersion: "7.0",
confirm: true
}
)

Para desactivar las características de 7.0 que persisten datos incompatibles con MongoDB 6.0, configura la compatibilidad de características a "6.0" en la implementación de MongoDB 7.0:

Nota

Ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin.

  • Para una instancia autónoma, ejecuta el comando en la instancia mongod autónoma.

  • Para un Set de réplicas, ejecuta el comando en el Primario. La mayoría de los miembros portadores de datos deben estar disponibles.

  • Para un clúster fragmentado, ejecuta el comando en una instancia mongos.

  • "6.0" featureCompatibilityVersion es compatible solo con las implementaciones de MongoDB 6.0 y MongoDB 7.0.

db.adminCommand(
{
setFeatureCompatibilityVersion: "6.0",
confirm: true
}
)

Si se ejecutan como parte del proceso de degradación de MongoDB 7.0 a MongoDB 6.0, también debes remover todas las características persistentes que sean incompatibles con 6.0. Consulta los procedimientos de degradación apropiados.

El siguiente ejemplo establece el campo opcional de nivel de confirmación de escritura wtimeout en 5000 (5 segundos).

Nota

Ejecuta el comando setFeatureCompatibilityVersion en la base de datos admin.

  • Para una instancia autónoma, ejecuta el comando en la instancia mongod autónoma.

  • Para un Set de réplicas, ejecuta el comando en el Primario. La mayoría de los miembros portadores de datos deben estar disponibles.

  • Para un clúster fragmentado, ejecuta el comando en una instancia mongos.

db.adminCommand( {
setFeatureCompatibilityVersion: "5.0",
writeConcern: { wtimeout: 5000 }
} )

If you experience startup issues after setting your feature compatibility version, contact MongoDB Support for assistance.

Volver

setClusterParameter