Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu

reshardCollection (comando de base de datos)

reshardCollection

Novedad 5.0 en la versiĂłn.:

El comando reshardCollection cambia la clave de particiĂłn de una colecciĂłn y cambia la distribuciĂłn de tus datos.

Tip

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

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 namespace de la colección que se reasignará. Toma 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">, ... }

Establecer los valores de campo en:

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.

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 agregar zonas, especifique las zonas de su colecciĂłn en un arreglo.

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

  • No cree Ă­ndices durante el proceso de reconfiguraciĂłn de particiones.

  • No inicie el proceso de redistribuciĂłn si hay creaciones de Ă­ndices en curso.

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.

Durante la fase de inicializaciĂłn, el coordinador de redistribuciĂłn determina la nueva distribuciĂłn de datos para la colecciĂłn particionada.

Durante la fase de Ă­ndice:

  • Cada destinatario de particiones crea una nueva colecciĂłn particionada vacĂ­a con las mismas opciones de colecciĂłn que la colecciĂłn particionada existente. Esta nueva colecciĂłn particionada es el destino donde las particiones receptoras 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 lo deseas, puedes forzar manualmente la finalización de la operación de redistribución emitiendo el comando 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 comando commitReshardCollection bloquea las escrituras antes y fuerza la finalización de la operación de redistribución de instancias. Durante el periodo en el que los guardados están bloqueados, tu aplicación experimenta un aumento en la latencia.

  • Una vez que el proceso de resharding alcanza la fase de confirmaciĂłn, es posible que ya no se pueda abortar con 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 reequilibrio instruye por separado a cada primario de particiones donante y receptor para que cambie el nombre de la colecciĂłn particionada temporal. La colecciĂłn temporal se convierte en la nueva colecciĂłn resharded.

  • Cada particiĂłn donante descarta la colecciĂłn particionada anterior.

El siguiente ejemplo redivide la colecciĂłn sales.orders con la nueva clave de particiĂłn { 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)
}