Definición
reshardCollectionNuevo en la versión 5.0.
El comando
reshardCollectioncambia la clave de partición de una colección y cambia la distribución de tus datos.Tip
En
mongosh, este comando también se puede ejecutar a través delsh.reshardCollection()método asistente.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.
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
Nota
Este comando es compatible con todos los clústeres de MongoDB Atlas. Para obtener información sobre el soporte de Atlas para todos los comandos, consulte 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.
Sintaxis
El comando tiene la siguiente sintaxis:
db.runCommand( { reshardCollection: "<database>.<collection>", key: <shardkey>, unique: <boolean>, numInitialChunks: <integer>, collation: { locale: "simple" }, zones: [ { min: <document with same shape as shardkey>, max: <document with same shape as shardkey>, zone: <string> | null }, ... ] } )
Campos de comandos
El comando toma los siguientes campos:
Campo | Tipo | Descripción |
|---|---|---|
| string | El espacio de nombres de la colección que se va a reparticionar. Tiene el |
| Documento | El documento que especifica el nuevo campo o los nuevos campos a utilizar como clave de partición.
Establezca los valores del campo en:
|
| booleano | opcional. Especifica si existe una restricción de unicidad en la clave de partición. Sólo se admite |
| entero | opcional. Especifica el número inicial de fragmentos que se crearán en todas las particiones del clúster al reorganizar una colección. El valor predeterminado es el número de fragmentos que existen para la colección bajo el patrón de clave de partición actual. A continuación, MongoDB creará y equilibrará los fragmentos a lo largo del clúster. El 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 |
| Documento | opcional. Si la colección especificada en |
| arreglo | Opcional. Para mantener o agregar zonas, especifique las zonas de su colección en una matriz. |
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.
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 conjunto de particiones donantes es idéntico a las particiones receptoras, a menos que utilices zonas.
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 índice
Durante la fase de índice:
Cada destinatario de un fragmento crea una nueva colección fragmentada vacía con las mismas opciones que la colección existente. Esta nueva colección fragmentada es el destino donde los fragmentos del destinatario escriben los nuevos datos.
Cada destinatario de particiones 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 no existe dicho índice en la colección particionada.
Clonar, Aplicar y Fase de puesta al día
Durante la clonación, la aplicación y la fase de actualización:
Cada destinatario de partición clona una copia inicial de los documentos que poseería bajo la nueva clave de partición.
Cada destinatario de la partición comienza a aplicar entradas del oplog de operaciones que sucedieron después de que el destinatario clonara los datos.
Cuando la estimación para el tiempo restante para completar la operación de resegmentación sea inferior a dos segundos, el coordinador de resegmentación bloqueará los guardados para la colección.
Nota
Si lo deseas, puedes forzar manualmente la finalización de la operación de redistribución emitiendo el comando
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 comandocommitReshardCollectionbloquea las escrituras antes y fuerza la finalización de la operación de redistribución de instancias. Durante el periodo en el que los guardados están bloqueados, tu aplicación experimenta un aumento en la latencia.
Fase de Compromiso
Una vez que el proceso de resharding alcanza la fase de confirmación, es posible que ya no se pueda abortar con
abortReshardCollection.Cuando todas las particiones han alcanzado una coherencia estricta, el coordinador de repartición concreta la operación de repartición e instala la nueva tabla de ruteo.
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.
Ejemplo
Reshard a Collection
El siguiente ejemplo vuelve a fragmentar la colección sales.orders con la nueva clave de fragmento { order_id: 1 }:
db.adminCommand({ reshardCollection: "sales.orders", key: { order_id: 1 } })
MongoDB devuelve lo siguiente:
{ ok: 1, '$clusterTime': { clusterTime: Timestamp(1, 1624887954), signature: { hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0), keyId: 0 } }, operationTime: Timestamp(1, 1624887947) }