Docs Menu
Docs Home
/ /

sh.reshardCollection() (método mongosh)

sh.reshardCollection(namespace, key, unique, options)

El sh.reshardCollection() El método cambia la clave de fragmento de una colección y cambia la distribución de sus datos.

Antes de volver a particionar una colección, lea el Requisitos y limitaciones de repartición.

Importante

Método mongosh

Esta página documenta un método mongosh. Esta no es la documentación para los comandos de base de datos ni para los drivers específicos de lenguajes, como Nodo.js.

Para el comando de base de datos, consulta el comando reshardCollection.

Para los drivers de API de MongoDB, consulte la documentación del driver de MongoDB específica del lenguaje.

sh.reshardCollection() toma los siguientes campos:

Campo
Tipo
Descripción

namespace

string

El espacio de nombres de la colección que se va a fragmentar en el "<database>.<collection>" formato.

key

Documento

El documento que especifica el nuevo campo o campos que se utilizarán como clave de fragmento.

{ <field1>: <1|"hashed">, ... }

Establezca los valores del campo en:

Véase también Índices de claves de fragmentos

unique

booleano

Opcional. Especifique si existe una restricción de unicidad en la clave de fragmento. Solo false se admite. El valor predeterminado false es.

options

Documento

Opcional. Un documento que contiene campos opcionales, incluidos numInitialChunks, collation, zones y forceRedistribution.

El campo options admite los siguientes campos:

Campo
Tipo
Descripción

numInitialChunks

entero

Opcional. Especifica el número inicial de fragmentos a crear en todas las particiones del clúster al reshardeando una colección. El valor por defecto es 90. Luego MongoDB crea y equilibra los fragmentos a lo largo del clúster. El numInitialChunks debe resultar en menos de 8192 por partición.

Si ves el error “La clave de partición proporcionada no tiene suficiente cardinalidad para generar la cantidad requerida de fragmentos”, vuelva a hacer el sharding en la colección con un valor de numInitialChunks menor.

A partir de MongoDB 8.2, las operaciones de re-fragmentación ignoran la configuración numInitialChunks cuando la clave de fragmento contiene un prefijo hash. En su lugar, MongoDB divide de forma determinista el espacio de la clave hash entre los destinatarios, utilizando el mismo enfoque que la creación inicial de fragmentos para colecciones hash vacías.

collation

Documento

Opcional. Si la colección especificada en reshardCollection tiene una intercalación predeterminada,debe incluir un documento de intercalación con;{ locale : "simple" } de lo contrario, el reshardCollection comando fallará.

zones

arreglo

Opcional. Especifica las zonas para la colección.

Para mantener o agregar zonas, especifique las zonas para su colección en una matriz:

[
{s
min: <document with same shape as shardkey>,
max: <document with same shape as shardkey>,
zone: <string> | null
},
...
]

forceRedistribution

booleano

Opcional. Si se establece en true, la operación se ejecuta incluso si la nueva clave de fragmento coincide con la anterior. Úselo con la opción zones para mover datos a zonas específicas.

Nuevo en la versión 8.0.

Este método está disponible en implementaciones alojadas en los siguientes entornos:

  • MongoDB Atlas: El servicio totalmente gestionado para implementaciones de MongoDB en la nube

Importante

Este comando no es compatible con los clústeres M0 y Flex. Para obtener más información, consulta Comandos no compatibles.

  • MongoDB Enterprise: La versión basada en suscripción y autogestionada de MongoDB

  • MongoDB Community: La versión de MongoDB con código fuente disponible, de uso gratuito y autogestionada.

Las creaciones de índices que ocurren durante el rehashing podrían fallar silenciosamente.

  • No cree índices durante el proceso de reorganización.

  • No inicie el proceso de re-segmentación si hay compilaciones de índices en curso.

Si la colección que está rehaciendo utiliza MongoDB Search, el índice de búsqueda deja de estar disponible al finalizar la rehaciendo. Debe reconstruir manualmente el índice de búsqueda una vez finalizada la rehaciendo.

En una operación de refragmentación de una colección, un fragmento puede ser:

  • donante, que actualmente almacena fragmentos para la colección fragmentada.

  • destinatario, que almacena nuevos fragmentos para la colección fragmentada en función de las claves y zonas del fragmento.

Un fragmento puede ser donante y receptor al mismo tiempo.

El servidor de configuración principal siempre es el coordinador de re-sharding e inicia cada fase de la operación de re-sharding.

Durante la fase de inicialización, el coordinador de fragmentación determina la nueva distribución de datos para la colección fragmentada.

Durante la fase de clonación:

  • Cada fragmento receptor crea una colección temporal vacía con las mismas opciones que la colección donante. Esta nueva colección es el destino donde los fragmentos receptores escriben los nuevos datos. Los fragmentos receptores no crean ningún índice, excepto el índice _id, hasta la fase de indexación.

  • Cada fragmento receptor clona los datos de la recopilación del fragmento donante, incluidos todos los documentos que el fragmento receptor posee bajo la nueva clave de fragmento.

Durante la fase de indexación, cada fragmento receptor crea los nuevos índices necesarios. Estos incluyen todos los índices existentes en la colección fragmentada y un índice compatible con el nuevo patrón de clave de fragmento, si dicho índice no existe ya en la colección fragmentada.

Cambiado en la versión 8.2.

Durante la fase de aplicación y recuperación:

  • Cada fragmento destinatario comienza a aplicar las entradas del registro de operaciones que se escribieron en el fragmento donante correspondiente después de que el destinatario clonara los datos.

  • Cuando la estimación del tiempo restante para completar la operación de refragmentación es inferior a ms, el fragmento donante bloquea las escrituras en la colección de 500 origen.

Nota

Si es necesario, puede forzar manualmente la finalización de la operación de refragmentación ejecutando el sh.commitReshardCollection() método. Esto resulta útil si el tiempo estimado actual para completar la refragmentación es aceptable para que su colección bloquee las escrituras. El método bloquea las escrituras anticipadamente y fuerza la finalización de la refragmentación. Durante el período en que se bloquean las sh.commitReshardCollection() escrituras, su aplicación experimenta un aumento de latencia.

Durante la fase de confirmación:

  • El coordinador de refragmentación espera a que todos los fragmentos alcancen una consistencia estricta y luego confirma la operación de refragmentación.

  • El coordinador de repartición indica a cada fragmento principal, donante y receptor, de forma independiente, que cambien el nombre de la colección temporal fragmentada. Esta se convierte en la nueva colección repartida.

  • Cada fragmento donante elimina la antigua colección de fragmentos.

Nota

Una vez que el proceso de re-fragmentación llega a la fase de confirmación, el proceso no se puede finalizar sh.abortReshardCollection() con.

El siguiente ejemplo vuelve a fragmentar la colección sales.orders con la nueva clave de fragmento { order_id: 1 }:

sh.reshardCollection( "sales.orders", { order_id: 1 } )

Ejemplo de salida:

{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp(1, 1624887954),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: 0
}
},
operationTime: Timestamp(1, 1624887947)
}

Para true sales.orders { order_id: 1 } redistribuir los datos con la misma clave de fragmento, configure forceRedistribution como. El siguiente ejemplo redistribuye los datos de la colección con la misma clave de fragmento.

sh.reshardCollection(
"sales.orders",
{ order_id: 1 },
{ forceRedistribution: true }
)

Ejemplo de salida:

{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp({ t: 1733502241, i: 20 }),
signature: {
hash: Binary.createFromBase64('AAAAAAAAAAAAAAAAAAAAAAAAAAA=', 0),
keyId: Long('0')
}
},
operationTime: Timestamp({ t: 1733502241, i: 20 })
}

Para obtener más detalles, consulte Cómo volver a fragmentar una colección en la misma clave de fragmento.

Vuelva a fragmentar una colección con zonas cuando necesite ajustar la distribución de datos entre los fragmentos de su clúster para cumplir con requisitos cambiantes o mejorar el rendimiento.

En el siguiente ejemplo, la colección test.scores reside en shard0 y shard1. La clave de fragmento actual es { _id: 1}.

1

En este ejemplo, esta zona se llama NewZone.

sh.addShardToZone( "shard2", "NewZone" )
sh.addShardToZone( "shard3", "NewZone" )
2
sh.reshardCollection(
"test.scores",
{ "studentId": 1, "testId": 1},
{ zones: [ {
min: { "studentId": MinKey(), "testId": MinKey() },
max: { "studentId": MaxKey(), "testId": MaxKey() },
zone: "NewZone" }
]
} )

La operación de repartición añade los fragmentos de la zona NewZone como destinatarios. El fragmento principal de la base de datos se añade como destinatario para compensar cualquier rango faltante en la definición de zona. Si no faltan rangos, la colección se clona en los fragmentos de la "Nueva Zona", como shard2 y shard3 en este ejemplo. sh.reshardCollection devuelve lo siguiente:

{
ok: 1,
'$clusterTime': {
clusterTime: Timestamp( { t: 1699484530, i: 54 } ),
signature: {
hash: Binary.createFromBase64( "90ApBDrSSi4XnCpV3OWIH4OGO0Y=", 0 ),
keyId: Long( "7296989036055363606" )
} },
operationTime: Timestamp( { t: 1699484530, i: 54 } )
}

Volver

sh.removeTagRange

En esta página