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 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
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
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>, ... }, ... ]
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.