moveChunk (comando de base de datos)

Definición

moveChunk

Comando administrativo interno. Movimientos chunks between partición. Emitir el moveChunk comando a través de una mongos instancia mientras se utiliza la base de datos admin. Use los siguientes formularios:

Tip

En mongosh, este comando también se puede ejecutar a través del método asistente sh.moveChunk().

Los métodos asistente son convenientes para usuarios de mongosh, pero es posible que no proporcionen el mismo nivel de información que los comandos de base de datos. En los casos en que no se necesite la conveniencia o se requieran campos de retorno adicionales, utiliza el comando de base de datos.

db.adminCommand( { moveChunk : <namespace> ,
                 find : <query> ,
                 to : <ID of the recipient shard>,
                 forceJumbo: <boolean>,
                 _secondaryThrottle : <boolean>,
                 writeConcern: <document>,
                 _waitForDelete : <boolean> } )

Alternativamente:

db.adminCommand( { moveChunk : <namespace> ,
                 bounds : <array> ,
                 to : <ID of the recipient shard>,
                 forceJumbo: <boolean>,
                 _secondaryThrottle : <boolean>,
                 writeConcern: <document>,
                 _waitForDelete : <boolean> } )

Nota

Utilice el comando para recuperar el ID del fragmento del listShards destinatario.

El comando tiene los siguientes moveChunk campos:

Campo	Tipo	Descripción
moveChunk	string	El namespace de la colección donde existe el fragmento. Especifica el namespace completo de la colección, incluyendo el nombre de la base de datos.
find	Documento	Una coincidencia de igualdad en la clave de fragmento que especifica el valor de la clave de fragmento del fragmento que se va a mover. Especifique el bounds campo o el find campo, pero no ambos.No utilice el find campo para seleccionar fragmentos en colecciones que utilicen una clave de fragmento con hash.
bounds	arreglo	Los límites de un fragmento específico que se va a mover. La matriz debe constar de dos documentos que especifiquen los valores de clave de fragmento inferior y superior del fragmento que se va a mover. Especifique el bounds campo o el find campo, pero no ambos. Use bounds para seleccionar fragmentos en colecciones que usen una clave de fragmento con hash.
to	string	El ID de la partición receptora para el fragmento.
fuerzaJumbo	booleano	opcional. Una bandera que determina si el comando puede mover un fragmento que es demasiado grande para migrar. La fragmento puede estar marcada o no como jumbo. Si true, el comando puede mover el fragmento. Si false, el comando no puede mover el fragmento. El valor es por defecto false. ADVERTENCIA: El comando moveChunk con forceJumbo=true bloquea las operaciones de guardado en la colección. Esta opción provoca que la partición migre fragmentos, incluso cuando son más grandes que el tamaño de fragmento configurado. La colección permanece no disponible para guardados durante la migración. Para migrar estos grandes fragmentos sin este largo período de bloqueo, consulta Balancear rangos que exceden el límite de tamaño en su lugar.
_secondaryThrottle	booleano	opcional. Para WiredTiger, por defecto es false. Si true, por defecto, cada movimiento de documento durante la migración de fragmentos se propaga al menos a un secundario antes de que el balanceador continúe con el siguiente documento. Esto es equivalente a un nivel de confirmación de escritura (write concern) de { w: 2 }. Utiliza la opción writeConcern para especificar un nivel de confirmación de escritura (write concern) diferente. Si false, el balanceador no espera la replicación en un secundario y continúa con el siguiente documento. Para obtener más información, consulte Acelerador secundario.
writeConcern	Documento	opcional. Un documento que expresa el nivel de confirmación de escritura (write concern) que el _secondaryThrottle utilizará para esperar a los secundarios durante la migración de fragmentos. writeConcern requiere _secondaryThrottle: true.
_waitForDelete	booleano	opcional. Si se establece en true, la fase de borrar de una operación moveChunk es bloqueante. _waitForDelete es por defecto false. Cuando se establece el campo _waitForDelete, MongoDB no espera en el orphanCleanupDelaySecs retraso antes de realizar la eliminación de rango. Si se utiliza el parámetro _waitForDelete y se realizan operaciones de lectura en secundarios, la lectura podría terminar debido a la fase de borrar de la migración. Para aprender más, consulta terminateSecondaryReadsOnOrphanCleanup.

El valor de bounds toma la forma:

[ { hashedField : <minValue> } ,
  { hashedField : <maxValue> } ]

La sección de migración de fragmentos describe cómo se mueven los fragmentos entre fragmentos en MongoDB.

Compatibilidad

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

• MongoDB Atlas: El servicio totalmente gestionado para implementaciones de MongoDB en la nube

• 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.

Considerations

Utiliza solo el moveChunk en circunstancias especiales, como al preparar tu clúster compartido para una primera ingesta de datos o una operación masiva de importación. En la mayoría de los casos, permite que el balanceador cree y equilibre fragmentos en clústeres fragmentados. Consulta Crear rangos en un clúster particionado para obtener más información.

Comportamiento

errmsg: "The collection's metadata lock is already taken."