Docs Menu
Docs Home
/ /

reshardCollection (comando de base de datos)

reshardCollection

Nuevo en la versión 5.0.

El reshardCollection El comando cambia la clave de fragmento de una colección y cambia la distribución de sus datos.

Tip

mongoshEn, este comando también se puede ejecutar a través del sh.reshardCollection() método auxiliar.

Los métodos asistente son convenientes para usuarios de mongosh, pero es posible que no proporcionen el mismo nivel de información que los comandos de base de datos. En los casos en que no se necesite la conveniencia o se requieran campos de retorno adicionales, utiliza el comando de base de datos.

Este comando está disponible en implementaciones alojadas en los siguientes entornos:

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

Nota

Este comando es compatible con todos los clústeres de MongoDB Atlas. Para obtener información sobre el soporte de Atlas para todos los comandos, consulte 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.

El comando tiene la siguiente sintaxis:

db.runCommand(
{
reshardCollection: "<database>.<collection>",
key: <shardkey>,
unique: <boolean>,
numInitialChunks: <integer>,
collation: { locale: "simple" },
zones: [
{
min: <document with same shape as shardkey>,
max: <document with same shape as shardkey>,
zone: <string> | null
},
...
]
}
)

El comando toma los siguientes campos:

Campo
Tipo
Descripción

reshardCollection

string

El espacio de nombres de la colección que se va a reparticionar. Tiene 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:

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.

numInitialChunks

entero

Opcional. Especifica el número inicial de fragmentos que se crearán en todos los fragmentos del clúster al volver a fragmentar una colección. El valor predeterminado es el número de fragmentos existentes para la colección según el patrón de clave de fragmento actual. MongoDB creará y equilibrará los fragmentos en todo el clúster. El valor numInitialChunks debe ser inferior a 8192 por fragmento.

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 predeterminada,debe incluir un documento de intercalación con;{ locale : "simple" } de lo contrario, el reshardCollection comando fallará.

zones

arreglo

Opcional. Para mantener o agregar zonas, especifique las zonas de su colección en una matriz.

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:

  • 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 a la vez. El conjunto de fragmentos donantes es idéntico al de los fragmentos receptores, a menos que se utilicen 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 receptor de fragmentos 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.

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

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

  • Cada destinatario de fragmentos comienza a aplicar entradas de registro de operaciones que ocurrieron después de que el destinatario clonó los datos.

  • Cuando la estimación del tiempo restante para completar la operación de refragmentación es inferior a dos segundos, el coordinador de refragmentación bloquea las escrituras para la colección.

    Nota

    Si lo desea, puede forzar manualmente la finalización de la operación de refragmentación mediante el commitReshardCollection comando. Esto es útil si el tiempo estimado actual para completar la refragmentación es aceptable para que su colección bloquee las escrituras. El comando bloquea commitReshardCollection las escrituras anticipadamente y fuerza la finalización de la refragmentación. Durante el período en que se bloquean las escrituras, su aplicación experimenta un aumento de latencia.

  • Una vez que el proceso de re-fragmentación llega a la fase de confirmación, ya no se puede abortar abortReshardCollection con.

  • Cuando todos los fragmentos han alcanzado una consistencia estricta, el coordinador de refragmentación confirma la operación de refragmentación e instala la nueva tabla de enrutamiento.

  • 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.

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

db.adminCommand({
reshardCollection: "sales.orders",
key: { order_id: 1 }
})

MongoDB devuelve lo siguiente:

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

Volver

eliminarFragmentoDeZona

En esta página