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 "Reshard to Shard" para particionar una colección y distribuir sus datos entre todas las particiones 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 realizar el re-sharding, debes calcular el clúster de tu 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 particiones, necesitarán un mínimo de 1.2TB de almacenamiento disponible por partición:
[ (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 de almacenamiento. Si no hay suficiente margen de maniobra en la CPU, debe escalar el clúster seleccionando un tamaño de instancia mayor.
Tip
Si tu clúster de MongoDB está alojado en Atlas, puedes utilizar la interfaz de usuario de Atlas para revisar las métricas de almacenamiento, CPU y margen de maniobra de E/S.
Requisitos de latencia
Debe garantizar que su aplicación pueda tolerar dos segundos en los que la colección que se está reparticionando bloquee las escrituras. Cuando se bloquean las operaciones de guardar, tu aplicación experimenta un aumento en la latencia. Si tu carga de trabajo no puede tolerar este requisito, utiliza migraciones por fragmentos para equilibrar tu 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 Queryable Encryption 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 redivide la colección info.productsInformation en su clave de partición actual { product_SKU : 1 }:
db.adminCommand( { reshardCollection: "info.productsInformation", key: { product_SKU : 1 }, forceRedistribution: true } )
Nota
Las operaciones de resharding ignoran la configuración numInitialChunks cuando la clave de partición contiene un prefijo encriptada. En su lugar, MongoDB divide determinísticamente el espacio de claves encriptada entre los destinatarios, utilizando el mismo enfoque que la creación inicial de fragmentos para colecciones iniciales de valores hash 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 los valores actualizados, debes 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 rehashing.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>, ... }, ... ]