Acerca de esta tarea
Volver a particionar a la misma clave de partición le permite utilizar la repatición como un mecanismo de movimiento de datos. Esto le permite:
Usa el Técnica defragmentación a fragmentación para fragmentar una colección y distribuir sus datos entre todos los fragmentos relevantes
Añade nuevas particiones más rápido
Remover particiones más rápidamente
Reescribe colecciones para recuperar espacio en disco.
La operación de redistribución realiza estas fases en orden:
La fase de clonación duplica los datos de la colección actual.
La fase de creación de índices construye índices en la colección reescalonada.
La fase de puesta al día aplica cualquier operación de guardar pendiente a la colección redistribuida.
La fase de confirmación renombra la colección temporal y descarta la colección antigua para realizar el corte.
Antes de comenzar
Antes de volver a fragmentar, debe calcular su clúster Requisitos de almacenamiento, Requisitos de latencia y cualquier Requisitos adicionales de recursos.
Requisitos de almacenamiento
Calcula el espacio de almacenamiento requerido para la operación de re-sharding sumando el tamaño de tu colección y el tamaño del índice, asumiendo una mínima oplog window de 24 horas usando esta fórmula:
Available storage required on each shard = [(collection size + index size) *2 ] / number of shards the collection will be distributed across.
Por ejemplo, una colección de 2TB y 400GB de índices distribuidos en 4 fragmentos necesitarán un mínimo de 1.2TB de almacenamiento disponible por fragmento:
[ (2 TB + 400GB) * 2 ] / 4 shards = 1.2 TB / shard
Debe confirmar que dispone del espacio de almacenamiento disponible en su clúster.
Si no hay suficiente espacio o margen de E/S disponible, debe aumentar el tamaño del almacenamiento. Si no hay suficiente margen de CPU, debe escalar el clúster seleccionando un tamaño de instancia mayor.
Tip
Si su clúster MongoDB está alojado en Atlas, puede usar la interfaz de usuario de Atlas para revisar las métricas de almacenamiento, CPU y espacio libre de E/S.
Requisitos de latencia
Debe asegurarse de que su aplicación pueda tolerar dos segundos en los que la colección que se está repartiendo bloquee las escrituras. Cuando se bloquean las escrituras, la aplicación experimenta un aumento de latencia. Si su carga de trabajo no puede soportar este requisito, utilice migraciones de fragmentos para equilibrar el clúster.
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.
Requisitos adicionales de recursos
Tu clúster debe cumplir estos requisitos adicionales:
Una ventana mínima de oplog window de 24 horas.
Capacidad de I/O inferior a 50%.
Carga de CPU por debajo del 80%.
Pasos
Redistribuye la colección.
Usa el Comando reshardCollection con la opción forceRedistribution configurada en true para reindexar la colección. El comando reshardCollection tiene la siguiente sintaxis:
db.adminCommand( { reshardCollection: "<database>.<collection>", key: { "<shardkey>" }, unique: <boolean>, numInitialChunks: <integer>, numSamplesPerChunk: <integer>, // New in MongoDB 8.0.20 collation: { locale: "simple" }, zones: [ { min: { "<document with same shape as shardkey>" }, max: { "<document with same shape as shardkey>" }, zone: <string> | null }, ], forceRedistribution: <bool> } )
Por ejemplo, este comando vuelve a fragmentar la colección info.productsInformation en su clave de fragmento actual { product_SKU : 1 }:
db.adminCommand( { reshardCollection: "info.productsInformation", key: { product_SKU : 1 }, forceRedistribution: true } )
Nota
A partir de MongoDB 8.2, las operaciones de redistribución ignoran la configuración numInitialChunks cuando 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.
Supervise la operación de resharding.
Para supervisar la operación de redistribución, puedes utilizar la etapa de pipeline $currentOp:
db.getSiblingDB("admin").aggregate( [ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ] )
Nota
Para ver valores actualizados, debe ejecutar el pipeline continuamente.
La $currentOp salida de la pipeline:
totalOperationTimeElapsedSecs: elapsed operation time en segundosremainingOperationTimeEstimatedSecs:: tiempo estimado restante en segundos para la operación de redistribución de particiones actual. Se devuelve como-1cuando se inicia una nueva operación de redistribución de particiones.A partir de MongoDB 7.0,
remainingOperationTimeEstimatedSecstambién está disponible en el coordinador durante una operación de reorganización.remainingOperationTimeEstimatedSecsse establece en una estimación de tiempo pesimista:La estimación de tiempo de la fase de actualización se establece en el tiempo de la fase de clonación, que es un periodo relativamente largo.
En la práctica, si sólo hay unas pocas operaciones de escritura pendientes, el tiempo real de la fase de sincronización es relativamente corto.
[ { shard: '<shard>', type: 'op', desc: 'ReshardingRecipientService | ReshardingDonorService | ReshardingCoordinatorService <reshardingUUID>', op: 'command', ns: '<database>.<collection>', originatingCommand: { reshardCollection: '<database>.<collection>', key: <shardkey>, unique: <boolean>, collation: { locale: 'simple' } }, totalOperationTimeElapsedSecs: <number>, remainingOperationTimeEstimatedSecs: <number>, ... }, ... ]