Acerca de esta tarea
Puede usar el resharding para distribuir sus colecciones particionadas a nuevas particiones. También puedes usarlo para remover particiones más rápido que las migraciones de fragmentos.
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
Agrega o remueve particiones en tu clúster.
Para agregar particiones a tu clúster, consulta Agregar particiones a un clúster. Para eliminar particiones de tu clúster, consulta Eliminar particiones de un clúster.
Reshard colecciones particionadas una a la vez con la misma clave de partición.
Usa el reshardCollection comando con la opción forceRedistribution para redistribuir datos en el clúster.
db.adminCommand( { reshardCollection: "<db>.<collection>", key: { "<shardkey>" }, forceRedistribution: true } )
El remezclado con forceRedistribution: true vuelve a escribir los datos en todas las particiones del clúster que no están en estado de drenando. Por defecto, la nueva partición utiliza numInitialChunks: 90. El remezclado crea al menos numInitialChunks - 1 fragmentos en un clúster. Si tienes más de 90 particiones, especifica un número mayor de numInitialChunks en el comando reshardCollection.
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>, ... }, ... ]
El resharding con forceRedistribution: true reescribe los datos de la colección en todos los fragmentos relevantes y descarta la colección antigua. Es el método más rápido para mover datos en un clúster.