Definición
sh.reshardCollection(namespace, key, unique, options)La
sh.reshardCollection()El método cambia la clave de partición de una colección y cambia la distribución de tus datos.Antes de reestructurar una colección, lee requisitos de redistribución y limitaciones de redistribución.
Importante
Método mongosh
Esta página documenta un método
mongosh. Esta no es la documentación para los comandos de base de datos ni para los drivers específicos de lenguajes, como Nodo.js.Para el comando de base de datos, consulta el comando
reshardCollection.Para los drivers de API de MongoDB, consulte la documentación del driver de MongoDB específica del lenguaje.
sh.reshardCollection()requiere los siguientes campos:CampoTipoDescripciónnamespacestring
El namespace de la colección para particionar en la forma
"<database>.<collection>".keyDocumento
El documento que especifica el nuevo campo o los nuevos campos a utilizar como clave de partición.
{ <field1>: <1|"hashed">, ... }Establezca los valores del campo en:
1para particionado basado en rango"hashed"para especificar una clave de fragmento con hash.
Véase también Índices de claves de fragmentos
uniquebooleano
opcional. Especifica si existe una restricción de unicidad en la clave de partición. Sólo se admite
false. Por defecto enfalse.optionsDocumento
Opcional. Un documento que contiene campos opcionales, incluidos
numInitialChunks,numSamplesPerChunk,collation,zonesyforceRedistribution.El campo
optionsadmite los siguientes campos:CampoTipoDescripciónnumInitialChunksentero
Opcional. Especifica el número inicial de fragmentos a crear en todas las particiones del clúster al reshardeando una colección. El valor por defecto es
90. Luego MongoDB crea y equilibra los fragmentos a lo largo del clúster. ElnumInitialChunksdebe resultar en menos de8192por partición.Si ves el error “La clave de partición proporcionada no tiene suficiente cardinalidad para generar la cantidad requerida de fragmentos”, vuelva a hacer el sharding en la colección con un valor de
numInitialChunksmenor.A partir de MongoDB 8.2, las operaciones de redistribución ignoran la configuración
numInitialChunkscuando la clave de partición contiene un prefijo encriptada. En cambio, MongoDB divide deterministicamente el espacio de claves encriptadas entre los recipientes, utilizando el mismo enfoque que para la creación inicial de los fragmentos en las colecciones encriptadas vacías.numSamplesPerChunkentero
Opcional. Especifica el número de documentos que se muestrearán en los nuevos fragmentos. Por defecto, MongoDB muestrea 10 documentos en cada fragmento.
Nuevo en la versión 8.0.20.
collationDocumento
opcional. Si la colección especificada en
reshardCollectiontiene una intercalación por defecto,debe incluir un documento de intercalación{ locale : "simple" }con, o elreshardCollectioncomando fallará.zonesarreglo
Opcional. Especifica las zonas para la colección.
Para mantener o agregar zonas, especifica las zonas para tu colección en un array:
[ {s min: <document with same shape as shardkey>, max: <document with same shape as shardkey>, zone: <string> | null }, ... ] forceRedistributionbooleano
opcional. Si se establece en
true, la operación se ejecuta incluso si la nueva clave de partición es igual a la antigua clave de partición. Usar con la opciónzonespara mover datos a zonas específicas.Nuevo en la versión 8.0.
Compatibilidad
Este método está disponible en implementaciones alojadas en los siguientes entornos:
MongoDB Atlas: El servicio totalmente gestionado para implementaciones de MongoDB en la nube
Importante
Este comando no es compatible con los clústeres M0 y Flex. Para obtener más información, consulta Comandos no compatibles.
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
Las creaciones de índices que ocurren durante el rehashing podrían fallar silenciosamente.
No cree índices durante el proceso de reorganización.
No inicie el proceso de re-segmentación si hay compilaciones de índices en curso.
Si la colección que estás redistribuyendo usa MongoDB Search, el índice de búsqueda se vuelve inaccesible cuando la operación de redistribución finaliza. Debes reconstruir manualmente el índice de búsqueda una vez completada la operación de redistribución.
Limitaciones de resharding
Si la colección usa Atlas Search, el índice de búsqueda dejará de estar disponible una vez que se complete la operación. Para restaurar, reconstruye manualmente el índice de búsqueda.
Las colecciones que utilizan cifrado consultable no son compatibles.
Proceso de re-partición
En una operación de refragmentación de una colección, un fragmento puede ser:
dador, que actualmente almacena los fragmentos para la colección particionada.
destinatario, que almacena nuevos fragmentos para la colección particionada en función de las claves de partición y zonas.
Una partición puede ser donante y receptor al mismo tiempo.
El servidor de configuración principal siempre es el coordinador de re-sharding e inicia cada fase de la operación de re-sharding.
Fase de inicialización
Durante la fase de inicialización, el coordinador de fragmentación determina la nueva distribución de datos para la colección fragmentada.
Fase de clonación
Durante la fase de clonación:
Cada partición receptora crea una colección particionada temporal y vacía con las mismas opciones de colección que la colección particionada donante. Esta nueva colección es el objetivo donde las particiones receptoras guardan los nuevos datos. Las particiones receptoras no crean ningún índice, excepto el índice
_idhasta la fase de índice.Cada partición receptora clona los datos de la colección de la partición donante, incluyendo todos los documentos que la partición receptora posee bajo la nueva clave de partición.
Fase de índice
Durante la fase de índice, cada partición destinataria construye los nuevos índices necesarios. Estos incluyen todos los índices existentes en la colección particionada y un índice compatible con el nuevo patrón de clave de partición si dicho índice aún no existe en la colección particionada.
Fase de aplicar y sincronización
Cambiado en la versión 8.2.
Durante la fase de aplicación y puesta al día:
Cada partición receptora comienza a aplicar las entradas de oplog que se escribieron en la partición donante correspondiente después de que la receptora clonó los datos.
Cuando la estimación del tiempo restante para completar la operación de redistribución está por debajo de 500 ms, la partición donante bloquea las escrituras en la colección fuente.
Nota
Si es necesario, puedes forzar manualmente la operación de resharding para que se complete utilizando el método sh.commitReshardCollection(). Esto es útil si la estimación actual de tiempo para completar la operación de resharding es una duración aceptable para el bloqueo de escrituras de tu colección. El método sh.commitReshardCollection() bloquea los guardados temprano y fuerza a que la operación de redistribución se complete. Durante el periodo en el que los guardados están bloqueados, tu aplicación experimenta un aumento en la latencia.
Fase de Compromiso
Durante la fase de confirmación:
El coordinador de refragmentación espera a que todos los fragmentos alcancen una consistencia estricta y luego confirma la operación de refragmentación.
El coordinador de repartición indica a cada fragmento principal, donante y receptor, de forma independiente, que cambien el nombre de la colección temporal fragmentada. Esta se convierte en la nueva colección repartida.
Cada partición donante descarta la colección particionada anterior.
Nota
Una vez que el proceso de redistribución alcance la fase de confirmación, el proceso no se puede finalizar con sh.abortReshardCollection()..
Ejemplos
Reshard a Collection
El siguiente ejemplo vuelve a fragmentar la colección sales.orders con la nueva clave de fragmento { order_id: 1 }:
sh.reshardCollection( "sales.orders", { order_id: 1 } )
Ejemplo de salida:
{ ok: 1, '$clusterTime': { clusterTime: Timestamp(1, 1624887954), signature: { hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0), keyId: 0 } }, operationTime: Timestamp(1, 1624887947) }
Reshard una colección con la misma clave de partición
Para realizar un reshard al mismo clave de partición, establezca forceRedistribution en true. El siguiente ejemplo vuelve a particionar la colección sales.orders con la misma clave de partición { order_id: 1 } y redistribuye los datos.
sh.reshardCollection( "sales.orders", { order_id: 1 }, { forceRedistribution: true } )
Ejemplo de salida:
{ ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1733502241, i: 20 }), signature: { hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0), keyId: Long('0') } }, operationTime: Timestamp({ t: 1733502241, i: 20 }) }
Para más detalles, consulta Repartir una colección de nuevo hacia la misma clave de partición.
Repartir una colección con zonas
Vuelva a fragmentar una colección con zonas cuando necesite ajustar la distribución de datos entre los fragmentos de su clúster para cumplir con requisitos cambiantes o mejorar el rendimiento.
En el siguiente ejemplo, la colección test.scores reside en shard0 y shard1. La clave de fragmento actual es { _id: 1}.
Ejecuta sh.reshardCollection con la nueva información de zona
sh.reshardCollection( "test.scores", { "studentId": 1, "testId": 1}, { zones: [ { min: { "studentId": MinKey(), "testId": MinKey() }, max: { "studentId": MaxKey(), "testId": MaxKey() }, zone: "NewZone" } ] } )
La operación de re-sharding agrega las particiones en la zona NewZone como recipientes. La partición primaria de la base de datos se añade como destinatario como respaldo para cualquier rango faltante en la definición de la zona. Si no hay rangos ausentes, la colección se clona en particiones del "NuevoSector", como shard2 y shard3 en este ejemplo. sh.reshardCollection devuelve lo siguiente:
{ ok: 1, '$clusterTime': { clusterTime: Timestamp( { t: 1699484530, i: 54 } ), signature: { hash: Binary.createFromBase64( "90ApBDrSSi4XnCpV3OWIH4OGO0Y=", 0 ), keyId: Long( "7296989036055363606" ) } }, operationTime: Timestamp( { t: 1699484530, i: 54 } ) }