/ /

Comandos de base de datos

Administración

Docs Home

Manual de MongoDB

Referencia

Comandos de base de datos

Administración

setFeatureCompatibilityVersion

Esta versión de la documentación se archivó y ya no se admite. Para actualizar tu implementación de 5.0, consulta el Procedimientos de actualización de MongoDB.6.0

Definición

setFeatureCompatibilityVersion: Activa o desactiva las características que mantienen datos incompatibles con versiones anteriores de MongoDB. Sólo 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.

Compatibilidad

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.

Sintaxis

El comando toma la siguiente forma:

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

Los valores para version son:

Versión	Descripción
`"5.0"`	Disponible en MongoDB 5.0. Implementaciones Activa las funcionalidades 5.0 que persisten datos incompatibles con MongoDB 4.4.
`"4.4"`	Disponible en las implementaciones de MongoDB 4.4 y 5.0 Habilita las características 4.4 que persisten datos incompatibles con MongoDB 4.2.
`"4.2"`	Disponible en implementaciones de MongoDB 4.4 Desactiva las funcionalidades de 4.4 que conservan datos incompatibles con MongoDB 4.2.

writeConcern

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.

Comportamiento

Conflictos con las operaciones en segundo plano

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

Fallos de sincronización

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.

Default Values

Implementaciones	`featureCompatibilityVersion`
Para las nuevas implementaciones 5.0	`"5.0"`
Para implementaciones 5.0 actualizadas desde 4.4	`"4.4"` hasta que `setFeatureCompatibilityVersion` a `"5.0"`.

Idempotencia

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.

Compatibilidad de características en árbitros

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

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

Ejemplos

Ver FeatureCompatibilityVersion

Para ver el featureCompatibilityVersion de una instancia mongod, ejecute el siguiente comando en una instancia mongod:

Nota

La operación no está definida en las instancias de mongos. Para un clúster fragmentado que tiene habilitado el control de acceso, para ejecutar el comando contra un miembro del set de réplicas de la partición, debes conectarte al miembro como un usuario local de la partición.

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

La salida de este comando se asemejará a una de las siguientes, dependiendo del estado actual del mongod:

Si el despliegue tiene la configuración por defecto de featureCompatibilityVersion, o si el comando setFeatureCompatibilityVersion se ha ejecutado correctamente contra el despliegue, el featureCompatibilityVersion tendrá la siguiente forma:
```
"featureCompatibilityVersion" : {
   "version" : <version>
}
```
Si el mongod está en un estado parcialmente actualizado o desactualizado, el featureCompatibilityVersion presenta la siguiente forma:
```
"featureCompatibilityVersion" : {
   "version" : <version> ,
   "targetVersion" : <target version>
}
```
Por ejemplo, si un clúster tiene un set de réplicas de partición que solo es de lectura cuando se ejecutar el comando setFeatureCompatibilityVersion contra el mongos, el comando fallará y el featureCompatibilityVersion de los servidores de configuración incluirá el campo targetVersion.
O si un conjunto de réplicas pasa a ser de solo lectura mientras setFeatureCompatibilityVersion se ejecuta, el comando fallará y el featureCompatibilityVersion del conjunto de réplicas targetVersion también incluirá el campo.

Establecer la versión de compatibilidad de funciones en las implementaciones de MongoDB 5.0

Activar funcionalidades incompatibles con versiones anteriores de 5.0

Para habilitar las funciones 5.0 que persisten datos incompatibles con MongoDB 4.4, configure la compatibilidad de funciones en "5.0" en la implementación de MongoDB 5.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: "5.0" } )

Desactivar funcionalidades incompatibles con la versión 5.0

Para desactivar las funcionalidades de la 5.0 que persisten datos incompatibles con MongoDB 4.4, configure la compatibilidad de funcionalidades en "4.4" en la implementación de MongoDB 5.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.

"4.4" featureCompatibilityVersion solo es compatible con implementaciones de MongoDB 4.4 y MongoDB 5.0.

db.adminCommand( { setFeatureCompatibilityVersion: "4.4" } )

Si se ejecuta como parte del proceso de reversión de MongoDB 5.0 a MongoDB 4.4, también debe remover todas las funcionalidades persistentes que sean incompatibles con 4.4. Consulta los procedimientos de degradación adecuados.

Establecer el Tiempo de Espera del Nivel de Confirmación de Escritura

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 }
} )

Volver

setAuditConfig

setIndexCommitQuorum