Nuevo en la versión 5.0.
La clave de partición ideal permite a MongoDB distribuir documentos de manera uniforme por todo el clúster mientras facilita patrones comunes de query. Una clave de partición subóptima puede provocar problemas de rendimiento o escalado debido a una distribución de datos desigual. A partir de MongoDB 5.0, puedes cambiar la clave de partición de una colección para modificar la distribución de tus datos en un clúster.
Nota
Antes de volver a fragmentar la colección, lea Solucionar problemas de clave de partición para obtener información sobre problemas comunes de rendimiento y escalado y consejos sobre cómo solucionarlos.
Acerca de esta tarea
Solo se puede volver a dividir la partición de una colección a la vez.
writeConcernMajorityJournalDefaultdebe sertrue.Para volver a fragmentar una colección que tenga una restricción de unicidad, la nueva clave de partición debe satisfacer los requisitos del índice único para cualquier índice único existente.
Los siguientes comandos y métodos de shell correspondientes no son compatibles con la colección que se está redividiendo durante la operación de redivisión:
Los siguientes comandos y métodos no son compatibles en el clúster mientras la operación de reajuste de particiones está en curso:
Advertencia
Utilizar cualquiera de los comandos anteriores durante una operación de redistribución de particiones provoca el fallo de la operación de redistribución de particiones.
Si la colección que se va a reequilibrar utiliza Búsqueda en Atlas, el índice de búsqueda dejará de estar disponible cuando se complete la operación de reequilibrio. Debes reconstruir manualmente el índice de búsqueda una vez que la operación de re-particionado se complete.
No se puede volver a dividir en fragmentos una colección de series de tiempo particionada.
Antes de comenzar
Antes de volver a dividir tu colección, asegúrate de cumplir los siguientes requisitos:
Tu aplicación puede tolerar un periodo de dos segundos en el que la colección que se está redistribuyendo bloquea los guardados. Durante el período en que las escrituras están bloqueadas, tu aplicación experimenta un aumento en la latencia. Si tu carga de trabajo no puede tolerar este requisito, considera refinando tu clave de partición en su lugar.
Su base de datos cumple con estos requisitos de recursos:
Espacio libre en almacenamiento: Asegúrate de que el espacio de almacenamiento disponible en cada partición en el cual se va a distribuir la colección sea al menos el doble del tamaño de la colección que deseas volver a compartir y su tamaño total de índice, dividido por el número de particiones.
storage_req = ( ( collection_size + index_size ) * 2 ) / shard_count Por ejemplo, considera una colección que contiene 2 TB de datos y tiene un índice de 400 GB distribuido en cuatro particiones. Para realizar una operación de resegmentación en esta colección, cada partición necesitaría 1.2 TB de almacenamiento disponible.
1.2 TB storage = ( ( 2 TB collection + 0.4 TB index ) * 2 ) / 4 shards Para cumplir con los requisitos de almacenamiento, es posible que necesite actualizar al siguiente nivel de almacenamiento durante la operación de redistribución. Puedes escalar a la baja una vez que la operación se complete.
E/S: Asegúrate de que tu capacidad de E/S esté por debajo del 50%.
Carga de la CPU: Asegúrate de que la carga de tu CPU esté por debajo del 80%.
Importante
Estos requisitos no son exigidos por la base de datos. Una falta de asignación de suficientes recursos puede provocar:
la base de datos se queda sin espacio y se apaga
rendimiento reducido
la operación de refragmentación está tomando más tiempo de lo esperado
Si tu aplicación tiene períodos de tiempo con menos tráfico, redistribuye tu colección durante ese tiempo si es posible.
Debe reescribir las queries de su aplicación para utilizar tanto la clave de partición actual como la nueva clave de partición.
Tip
Si tu aplicación puede tolerar tiempos de inactividad, puedes realizar estos pasos para evitar reescribir las queries de la aplicación para usar tanto la clave de partición actual como la nueva:
Detén tu aplicación.
Reescribe tu aplicación para usar la nueva clave de partición.
Espere hasta que se complete el nuevo particionamiento. Para supervisar el proceso de redistribución, utilice la etapa de
$currentOppipeline.Implementa tu aplicación reescrita.
Antes de que finalice el resharding, las siguientes queries generan un error si el filtro de query no incluye ni la clave de partición actual ni un campo único (como
_id):Para un rendimiento óptimo, recomendamos que también reescribas otras consultas para incluir la nueva clave de partición.
Una vez completada la operación de refragmentación, puedes remover la clave de partición anterior de las consultas.
No existen procesos de creación de índices en curso. Utiliza
db.currentOp()para comprobar si hay procesos activos de creación de índices:db.adminCommand( { currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] } ) En el documento de resultados, si el valor en el campo
inproges un arreglo vacío, no hay creaciones de índices en curso:{ inprog: [], ok: 1, '$clusterTime': { ... }, operationTime: <timestamp> }
Nota
El reenrutamiento es un proceso de guardar intensivo que puede generar tasas aumentadas de oplog. Puedes optar por:
defina un tamaño fijo para el oplog para prevenir el crecimiento sin límites del oplog.
aumente el tamaño de Oplog para minimizar la posibilidad de que uno o más nodos secundarios queden obsoletos.
Consulta la documentación de Oplog del set de réplicas para obtener más información.
Pasos
Importante
Recomendamos encarecidamente que primero revises Acerca de esta tarea y leas la sección Pasos en su totalidad antes de realizar la redistribución de tu colección.
En una operación de re-sharding de una colección, una partición 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 primario es siempre el coordinador de replanificación y comienza cada fase de la operación de replanificación.
Desactivar el balanceador
Debes desactivar el balanceador antes de comenzar el proceso de repartición de una colección. Para desactivar el balanceador, consulte aquí.
Inicie la operación de re-sharding.
Mientras esté conectado al mongos, emite un comando reshardCollection que especifique la colección a redistribuir y la nueva clave de partición:
db.adminCommand({ reshardCollection: "<database>.<collection>", key: <shardkey> })
MongoDB establece el número máximo de segundos para bloquear guardados en dos segundos y comienza la operación de redistribución de particiones.
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, es necesario ejecutar continuamente la pipeline anterior.
La $currentOp salida de la pipeline:
totalOperationTimeElapsedSecs: elapsed operation time en segundosremainingOperationTimeEstimatedSecs: tiempo estimado restante en segundos para la operación de reestructuración actual. Se devuelve como-1cuando comienza una nueva operación de reestructuración.Empezando en:
MongoDB 5.0, pero antes de MongoDB 6.1,
remainingOperationTimeEstimatedSecssolo está disponible en una partición receptora durante una operación de redistribución de fragmentos.MongoDB 6.1,
remainingOperationTimeEstimatedSecstambién está disponible en el coordinador durante una operación de reasignación de particiones.
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 puesta al día aplica cualquier operación de guardar pendiente a la colección redistribuida.
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>, ... }, ... ]
Vuelva a habilitar el balanceador.
Para habilitar el balanceador, consulte aquí.
Comportamiento
Duración mínima de una operación de redistribución
La duración mínima de una operación de redistribución de fragmentos siempre es de 5 minutos.
Escrituras reintentables
Se pueden reintentar las escrituras reintentables iniciadas antes o durante el reshardeo, durante y después de que la colección haya sido reshardeada, durante hasta 5 minutos. Después de 5 minutos es posible que no puedas encontrar el resultado definitivo del guardado y los intentos posteriores de volver a intentar el guardado fallan con un error IncompleteTransactionHistory.
Caso de error
Duplicate _id Values
La operación de redistribución falla si los valores de _id no son globalmente únicos para evitar la corrupción de los datos de la colección. Los valores duplicados de _id también pueden impedir que la migración de fragmentos tenga éxito. Si tienes documentos con valores duplicados de _id, copia los datos de cada uno en un nuevo documento y luego elimina los documentos duplicados.