Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/ /

sh.reshardCollection() (método mongosh)

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

Nuevo en la versión 5.0.

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

Antes de reestructurar una colección, lee requisitos de redistribución y limitaciones de redistribució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() requiere los siguientes campos:

Campo
Tipo
Descripción

namespace

string

El namespace de la colección para particionar en la forma "<database>.<collection>".

key

Documento

El documento que especifica el nuevo campo o los nuevos campos a utilizar como clave de partición.

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

Establezca los valores del campo en:

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

unique

booleano

opcional. Especifica si existe una restricción de unicidad en la clave de partición. Sólo se admite false. Por defecto en false.

options

Documento

opcional. Un documento que contenga campos opcionales, incluidos numInitialChunks, collation y zones.

El campo options admite los siguientes campos:

Campo
Tipo
Descripción

numInitialChunks

entero

opcional. Especifica el número inicial de fragmentos que se crearán en todas las particiones del clúster al reorganizar una colección. El valor predeterminado es el número de fragmentos que existen para la colección bajo el patrón de clave de partición actual. A continuación, MongoDB creará y equilibrará 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.

collation

Documento

opcional. Si la colección especificada en reshardCollection tiene una intercalación por defecto,debe incluir un documento de intercalación { locale : "simple" } con, o el reshardCollection comando fallará.

zones

arreglo

Opcional. Para mantener o añadir zonas, especifique las zonas de su colección en una matriz:

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

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.

En una operación de refragmentación de una colección, un fragmento 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 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 índice:

  • Cada destinatario de un fragmento crea una nueva colección fragmentada vacía con las mismas opciones que la colección existente. Esta nueva colección fragmentada es el destino donde los fragmentos del destinatario escriben los nuevos datos.

  • Cada destinatario de particiones construye los nuevos índices necesarios. Estos incluyen todos los índices existentes en la colección particionada y un índice compatible con el nuevo patrón de clave de partición si no existe dicho índice en la colección particionada.

Durante la clonación, la aplicación y la fase de actualización:

  • Cada destinatario de partición clona una copia inicial de los documentos que poseería bajo la nueva clave de partición.

  • Cada destinatario de la partición comienza a aplicar entradas del oplog de operaciones que sucedieron después de que el destinatario clonara los datos.

  • Cuando la estimación para el tiempo restante para completar la operación de resegmentación sea inferior a dos segundos, el coordinador de resegmentación bloqueará los guardados para la colección.

    Nota

    Si es necesario, puedes forzar manualmente la operación de resharding para que se complete utilizando el método sh.commitReshardCollection(). Esto es útil si la estimación actual de tiempo para completar la operación de resharding es una duración aceptable para el bloqueo de escrituras de tu colección. El método sh.commitReshardCollection() bloquea los guardados temprano y fuerza a que la operación de redistribución se complete. Durante el periodo en el que los guardados están bloqueados, tu aplicación experimenta un aumento en la latencia.

  • Después de que el proceso de resharding alcance la fase de confirmación, el proceso no podrá finalizar con sh.abortReshardCollection().

  • Cuando todas las particiones han alcanzado una coherencia estricta, el coordinador de repartición concreta la operación de repartición e instala la nueva tabla de ruteo.

  • 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 partición donante descarta la colección particionada anterior.

    Tip

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)
}

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 re-sharding agrega las particiones en la zona NewZone como recipientes. La partición primaria de la base de datos se añade como destinatario como respaldo para cualquier rango faltante en la definición de la zona. Si no hay rangos ausentes, la colección se clona en particiones del "NuevoSector", 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