Optimice la migración de datos en MongoDB: técnicas de fragmentación para velocidad y escalabilidad

¿Necesita fragmentar una colección de 2 TB y distribuir los datos entre todos sus fragmentos en menos de 24 horas? ¡Aproveche el resharding para acelerar su migración de datos!

En esta publicación, cubriremos una técnica llamada "reshard-to-shard" que usa resharding para distribuir datos a través de los fragmentos en su clúster rápidamente.

Repasaremos:

1. Consideraciones antes y durante la migración.
2. Cómo iniciar, monitorear y cancelar la migración de datos más rápida.

Si es nuevo en el sharding o desea un repaso sobre cómo MongoDB ofrece escalabilidad horizontal, consulte el Manual de MongoDB .

Tabla de contenido

• Fondo
• ¿Cuáles son los beneficios de reshard-to-shard?
• ¿Cuándo debo usar reshard-to-shard?
• ¿Cuándo no debo usar reshard-to-shard?
• ¿Cuáles son los requisitos previos de fragmento a fragmento?
• Descripción general de la técnica de fragmento a fragmento
• Ejemplo de fragmento a fragmento
• preguntas frecuentes

Fondo

Cuando una colección se fragmenta inicialmente en un clúster de varios fragmentos, el equilibrador comienza a migrar datos del fragmento que contiene la colección fragmentada recientemente a los otros fragmentos del clúster para distribuir equitativamente la colección entre los fragmentos. Cuando el balanceador está migrando datos, un fragmento solo puede participar en una migración a la vez, sin importar cuántas colecciones necesiten migrarse. Lo que significa que en un clúster de 3 fragmentos, solo dos fragmentos a la vez pueden migrar datos entre ellos. Resharding no comparte las mismas limitaciones debido a las diferencias de ejecución interna.

Debido a que volver a fragmentar está reescribiendo todos los datos, puede escribir datos en paralelo en todos los fragmentos del clúster, lo que aumenta el rendimiento y reduce en gran medida el tiempo para migrar datos entre los fragmentos en relación con lo que puede lograr el equilibrador. Resharding crea una nueva colección con una nueva clave de fragmento en segundo plano en cada uno de los fragmentos mientras mantiene su colección existente disponible para que la utilice su aplicación. Una vez que todos los documentos se clonan en la nueva colección, se produce la transición. La colección existente con la clave de fragmento anterior se descarta en favor de la nueva colección creada por la operación de fragmentación.

¿Cuáles son los beneficios de reshard-to-shard?

Primero, ¡es mucho más rápido! Al aprovechar la repartición, un cliente pudo fragmentar y distribuir su colección de 3,5 TB en 4 fragmentos en 22,5 horas. El mismo proceso habría tomado 30 días si se hubiera dejado con el método predeterminado de migraciones de fragmentos del balanceador.

En segundo lugar, ¡tiene un impacto mínimo en su carga de trabajo! Después de que el equilibrador migre los datos, debe realizar una operación de limpieza llamada borrado de rango en el fragmento que donó los datos, ya que solo un fragmento puede poseer cada documento específico. La eliminación de rangos es una operación intensiva de E/S que puede afectar el rendimiento de su clúster. Repartir no necesita llevar a cabo la eliminación de rango, ya que realiza una eliminación de la colección anterior después de que pasa a la nueva colección con la nueva clave de fragmento.

En tercer lugar, automáticamente recupera su espacio en disco. Al eliminar la colección anterior, se libera espacio de almacenamiento para que lo utilice cualquier colección sin tener que ejecutar una operación como compacto . Esto significa que puede reducir el almacenamiento de forma más rápida y sencilla después de la operación, si lo desea.

Por ejemplo, un cliente consumía casi 2,8 TB en shard0 antes de que se completara la operación de fragmentación de su colección más grande.

Cuando finalizó el resharding, ¡se devolvieron inmediatamente 1,9 TB de espacio de almacenamiento! Pasaron de consumir 2,7 TB de almacenamiento a 873 GB de almacenamiento.

¿Cuándo debo usar reshard-to-shard?

Respuesta: Cuando inicialmente está fragmentando una colección de cualquier tamaño en cualquier cantidad de fragmentos.

Hay algunos escenarios en los que el equilibrio puede ser más rápido (por ejemplo, menos de 100 GB), pero aún debe tener en cuenta la eliminación del rango y la recuperación del almacenamiento a través de la sincronización inicial o compacta . Por lo tanto, si tiene la capacidad, le recomendamos volver a fragmentar sin importar cuán grande sea la colección que desea fragmentar.

¿Cuándo no debo usar reshard-to-shard?

No debe usar la táctica de fragmento a fragmento cuando:

• Su aplicación no puede tolerar un bloqueo de escrituras durante dos segundos para permitir la transición a la colección fragmentada.

  • La duración de las escrituras que se pueden bloquear para la colección que se está repartiendo por defecto es de dos segundos, hay un parámetro configurable que puede modificar la duración del bloqueo.

    
    

• Su colección es una colección de series temporales
  • Si intenta volver a dividir una colección de serie temporal, recibirá un mensaje de error que indica que no se admite volver a dividir una colección de serie temporal.

Para los escenarios enumerados anteriormente, use el método tradicional de fragmentar una colección y dejar que el equilibrador migre los datos.

¿Cuáles son los requisitos previos de fragmento a fragmento?

1. Un clúster de MongoDB que ejecuta MongoDB 5.0 o superior
2. Debe seleccionar una clave de fragmento adecuada para su colección.
3. Cree los índices necesarios para admitir tanto la clave de fragmento temporal como la clave de fragmento deseada.
4. Además, dado que usará resharding para acelerar las velocidades de migración de datos, familiarícese con el requisitos y limitaciones de resharding .

Para ejecutar con éxito una operación de fragmentación, su clúster debe tener:

• 1,2 veces el tamaño de la colección por fragmento disponible en cada fragmento.
  • Por ejemplo, si está fragmentando una colección de 1 TB en 4 fragmentos, el tamaño de la colección fragmentada es de 250 GB por fragmento cuando se distribuye en 4 fragmentos. Desea tener un mínimo de 300 GB de almacenamiento disponible en cada fragmento.
• Capacidad de E/S por debajo del 50 %
• Uso de CPU por debajo del 80%

Los clientes que usan Atlas cuyo clúster no cumple con los requisitos de almacenamiento, E/S y CPU para ejecutar la fragmentación pueden escalar su grupo y/o personalizar el almacenamiento para aumentar los recursos de su clúster para permitir una operación de fragmentación exitosa. Pueden volver a la normalidad una vez finalizada la operación.

Descripción general de la técnica de fragmento a fragmento

Hay dos pasos muy simples para ejecutar una operación de fragmento a fragmento:

1. Fragmento en una clave de fragmento temporal
2. Reshard en la clave de fragmento deseada

¿Por qué primero fragmentaría en una clave fragmentada temporal y eso no dañaría mi aplicación?

¡Vamos a explicar!

Paso uno: fragmento con una clave de fragmento temporal

Actualmente, volver a fragmentar no admite volver a fragmentar en la misma clave de fragmento (se realizará correctamente como "no operativo" porque ya se encuentra en el estado deseado). Para sortear esta limitación, la técnica de fragmento a fragmento requiere la fragmentación intencional en una clave de fragmento temporal que sea diferente de la clave de fragmento deseada. Debido a la compatibilidad de MongoDB con la fragmentación de rango y la fragmentación hash, la clave de fragmento temporal puede modificarse muy levemente a partir de la clave de fragmento deseada que seleccionó para su colección.

La clave de fragmento temporal debe seleccionar una estrategia de partición diferente solo para uno de sus campos de clave de fragmento. Debido a las limitaciones de determinadas consultas, como updateOne(), updateMany(), deleteOne(), etc., que requieren que la consulta incluya la clave de fragmento, utilizará una estrategia de partición diferente. MongoDB usa estrategias de partición solo como una forma de determinar cómo distribuir sus datos a través de los fragmentos en su clúster y no cambia los valores en el documento. Lo que significa que su aplicación puede utilizar una consulta updateOne u otra que requiera la clave de fragmento con ambas estrategias de partición.

Por ejemplo, si la clave de fragmento deseada que seleccionó para su colección es:

 {"_id": "hashed"}

La clave de fragmento temporal que se usará inicialmente para su colección debe ser:

 {"_id": 1}

Para las claves de partición compuestas, solo uno de sus campos de clave de partición necesita usar una estrategia de partición diferente. Por ejemplo, si la clave de fragmento deseada que seleccionó para su colección es:

 { launch_vehicle: 1, payload: 1}

Su clave de fragmento temporal debe ser:

 { launch_vehicle: 1, payload: "hashed"}

La táctica de fragmentación a fragmentación requiere una fragmentación inmediata en la clave de fragmentación que usará a largo plazo después de que se complete la fragmentación inicial de la colección con la clave de fragmentación temporal. Esto mantiene más del 99 % de los datos en un fragmento mientras se ejecuta la operación de fragmentación, lo que reduce significativamente el impacto de las consultas de difusión.

Si desea asegurarse de que el 100 % de sus datos estén en un fragmento, puede apagar el equilibrador antes de fragmentar inicialmente la colección con la clave de fragmento temporal. Deshabilitar el equilibrador garantiza que no se produzcan migraciones antes de que se inicie la fragmentación. Cubriremos cómo puede apagar el balanceador en el siguiente ejemplo.

Dado que habrá creado ambos índices para su clave fragmentada temporal y deseada, mientras se lleva a cabo la operación de fragmentación, las consultas que utilicen la clave fragmentada deseada tendrán un rendimiento ya que pueden aprovechar el índice para la clave fragmentada deseada mientras su colección se divide temporalmente. por su clave de fragmento temporal.

Paso dos: vuelva a dividir en la clave de fragmento deseada

El segundo paso es ejecutar una operación normal de fragmentación, excepto que está aprovechando un efecto secundario de cómo funciona la fragmentación para su beneficio.

Resharding tiene cuatro fases principales:

• Inicialización : se muestrea la colección que se está fragmentando y se determina una nueva distribución de datos basada en la nueva clave de fragmento.

  
  

• Índice : la operación de creación de fragmentos crea una nueva colección fragmentada temporal vacía en todos los fragmentos en función de la nueva clave de fragmento y crea los índices, incluidos los índices de clave que no son fragmentos que admiten la colección existente.

  
  

• Clonar, ponerse al día y aplicar : los documentos se clonan en los fragmentos de acuerdo con la nueva clave de fragmento, y se aplica cualquier modificación a los documentos mientras se ejecutaba la operación de creación de fragmentos.

  
  

• Confirmar : la colección temporal cambia de nombre y ocupa el lugar de la colección que se está fragmentando y la colección ahora antigua se elimina.

Después de revisar las fases anteriores, puede ver cómo obtendrá el beneficio del movimiento rápido de datos, una colección fragmentada que se distribuye equitativamente entre sus fragmentos una vez que se completa la operación y el espacio de almacenamiento liberado, todo de una sola vez.

Una vez que se completa la operación de creación de fragmentos, puede realizar operaciones de limpieza, como eliminar el índice de clave de fragmento temporal y reducir su clúster y/o su almacenamiento para adaptarse a sus necesidades de estado estable.

Ejemplo de fragmento a fragmento

Supongamos que está trabajando en una aplicación que rastreará aviones comerciales para que los clientes puedan ser notificados si es probable que su vuelo se retrase. Estudió los patrones de consulta de su aplicación y revisó qué atributos contribuyen a una buena clave de fragmento.

La clave de fragmento que ha seleccionado para su colección es:

 { airline: 1, flight_number: 1, date: "hashed" }

Con la clave de fragmento determinada, puede comenzar a verificar los requisitos previos para ejecutar una operación de fragmento a fragmento. Primero, genera su clave de fragmento temporal. Como se indicó anteriormente, desea que su clave de fragmento temporal sea una versión ligeramente modificada de la clave de fragmento deseada.

Entonces, la clave de fragmento temporal que ha seleccionado es:

 { airline: 1, flight_number: 1, date: 1}

A continuación, crea los índices para que admitan las claves fragmentadas temporales y finales.

Los índices se pueden crear usando el shell de Mongo a través del comando db.collection.createIndexes() :

 db.flight_tracker.createIndexes([ {"airline": 1, "flight_number": 1, date: "hashed"}, {"airline": 1, "flight_number": 1, date: 1} ])

Las compilaciones de índice se pueden monitorear usando mongo shell a través del siguiente comando:

 db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] })

Si desea asegurarse de que no se produzcan migraciones entre la fragmentación de su colección y cuando se invoca la fragmentación, puede desactivar el equilibrador ejecutando el siguiente comando:

 sh.stopBalancer()

Si su clúster de MongoDB se implementa en Atlas, puede usar la interfaz de usuario de Atlas para revisar fácilmente las métricas disponibles que le informan que su clúster tiene suficiente almacenamiento libre disponible más el margen de CPU y E/S para realizar una operación de fragmentación.

Si no hay suficiente espacio de almacenamiento disponible o margen de E/S, puede escalar el almacenamiento. Por falta de margen de CPU, puede escalar el clúster. El escalado tanto del almacenamiento como del clúster se realiza fácilmente a través de la interfaz de usuario de Atlas.

Acceder a la configuración del clúster es simple y se puede hacer desde la pantalla de descripción general de su grupo, que muestra todos los clústeres implementados para el grupo.

Una vez cumplidos todos los requisitos previos, puede comenzar la primera parte del proceso de fragmento a fragmento: fragmentar la colección con la clave de fragmento temporal.

Luego puede usar Mongo shell y el comando sh.shardCollection() para fragmentar la colección:

 sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: 1} )

sh.shardCollection() devolverá un documento cuando esté completo, el campo ok tendrá un valor de 1 si la operación fue exitosa.

 { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) }

Una vez que se fragmenta la colección, ¡puede pasar inmediatamente a fragmentar la colección!

Para volver a fragmentar su colección en la clave de fragmento deseada, use sh.reshardCollection() en mongo Shell:

 sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" })

Si ejecuta el comando sh.status() en mongo shell, verá una nueva colección en la salida con el formato del nombre de la nueva colección <db_name>.system.resharding.<UUID> . Esta es la colección que resharding está construyendo y distribuyendo los datos de acuerdo con la clave de fragmento deseada

Para monitorear el estado de la operación de fragmentación para la colección flight_tracker, puede usar el siguiente comando

 db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "main.flight_tracker" } } ])

El resultado del comando le informará en qué etapa se está ejecutando actualmente la operación de fragmentación y el tiempo estimado de finalización a través del campo RestanteOperationTimeEstimatedSecs. ¡Tenga en cuenta que el tiempo estimado para completar el intercambio es pesimista y que las operaciones de redistribución toman mucho menos tiempo del informado!

La operación de fragmentación debería estar a punto de finalizar cuando el tamaño de los datos de cada fragmento haya aumentado según el tamaño de la colección que se fragmenta dividido por la cantidad de fragmentos en el clúster. Por ejemplo, una colección de 1 TB que se fragmenta en 4 fragmentos, la operación de fragmentación debe completarse cuando cada fragmento haya escrito 250 GB (sin tener en cuenta la inserción, actualización o eliminación de otros datos en el fragmento).

Si su clúster está implementado en Atlas, también puede monitorear el progreso de la operación de fragmentación a través de la interfaz de usuario de Atlas usando la pestaña Métricas del clúster.

• Para los clústeres de Atlas que ejecutan MongoDB 6.0 y versiones posteriores, puede usar la opción de visualización del tamaño de los datos del fragmento y luego seleccionar una colección con una sintaxis de <db_name>.system.resharding.<UUID> . Esta vista aísla la colección temporal y solo mostrará el crecimiento del tamaño de los datos de la nueva colección.

  
  

• Para los clústeres de Atlas que ejecutan MongoDB 5.0, puede usar la opción de visualización de tamaño de datos lógicos de db. Esta vista no permite el aislamiento a nivel de colección.

  
  

Mientras se ejecuta la fragmentación, las tres métricas del clúster que debe supervisar principalmente son:

• Almacenamiento disponible: consumir todo el almacenamiento disponible puede provocar inestabilidad en el clúster
• Utilización de la CPU: una alta utilización de la CPU puede provocar un rendimiento degradado del clúster
• Uso de E/S: el uso de E/S por encima de su capacidad puede provocar una degradación del rendimiento del clúster

Si alguna vez le preocupa que la fragmentación afecte negativamente a su clúster, puede cancelar instantáneamente la operación de fragmentación antes de que llegue a la parte de confirmación del proceso mediante el siguiente comando:

 sh.abortReshardCollection("main.flight_tracker")

Si desactivó el equilibrador para asegurarse de que no se produzcan migraciones entre la fragmentación y la fragmentación de la colección, vuelva a activar el equilibrador ahora con el siguiente comando:

 sh.startBalancer()

La operación de fragmentación cuando finalice devolverá si la operación fue exitosa o no al cliente que invocó.

Dado que la fragmentación es una operación de ejecución prolongada y es posible que haya cerrado esa sesión de shell de Mongo, puede verificar si la operación de fragmentación aún se está ejecutando utilizando la agregación de monitoreo de fragmentación si desea detalles o sh.estado() para ver si la colección temporal todavía está presente en la salida. Si la agregación de fragmentación no devuelve nada o si ya no ve una colección temporal en la salida de sh.status(), la operación de fragmentación ha finalizado.

Puede usar db.collection.getShardDistribution para determinar si la operación fue exitosa:

 db.flight_tracker.getShardDistribution()

Si la repartición se completó correctamente, debería ver un resultado en el que la distribución es igual entre los fragmentos.

• Para MongoDB 6.0 y mayores, la uniformidad está determinada por el tamaño de los datos por fragmento, por lo que debería ver una cantidad de datos casi igual en cada uno de los fragmentos en la salida de db.collection.getShardDistribution.

  
  

• Para MongoDB 5.0, la uniformidad está determinada por la cantidad de fragmentos por fragmento, por lo que debería ver un número igual de fragmentos en cada uno de los fragmentos en la salida de db.collection.getShardDistribution.

Si su clúster se implementa en Atlas, puede usar la interfaz de usuario de Atlas a través de la pestaña Métricas para determinar si la operación de fragmentación es exitosa.

• Para los clústeres de Atlas que ejecutan MongoDB 6.0 y versiones posteriores, puede usar la opción de visualización del tamaño de los datos del fragmento y luego seleccionar la colección que se sometió a un nuevo fragmento. Debería ver una cantidad igual de datos por fragmento mostrado.

  
  

• Para los clústeres de Atlas que ejecutan MongoDB 5.0, puede usar la opción de visualización de fragmentos y luego seleccionar su colección que se sometió a la fragmentación. Debería ver una cantidad casi igual de fragmentos en todos los fragmentos de su clúster.

  
  

Tanto para el tamaño de los datos del fragmento como para la cantidad de fragmentos, la interfaz de usuario de Atlas mostrará un fuerte aumento en la métrica relevante debido a la fragmentación utilizando un formato de nombre de colección de <db_name>.system.resharding.<UUID> temporalmente antes de cambiarle el nombre y eliminar el antiguo colección con la antigua clave de fragmento.

Si se aborta el cambio de fragmentos, la salida de db.collection.getShardDistribution probablemente mostrará la mayoría de los datos en el fragmento en el que se fragmentó inicialmente la colección. Las anulaciones con la fragmentación son poco frecuentes y probablemente se deban a que la fragmentación no pudo realizar el corte de la recopilación en 2 segundos o menos.

Si ese es el caso, recomendamos programar el inicio de la fragmentación para que intente comprometerse durante un período de menor tráfico para su clúster. Alternativamente, si su aplicación puede tolerar un bloqueo de escrituras durante más de 2 segundos, puede modificar el tiempo de confirmación aumentando la duración con el parámetro reshardingCriticalSectionTimeoutMillis más allá del valor predeterminado de 2000ms.

Una vez que se completa la operación de fragmentación, puede realizar operaciones de limpieza, como eliminar el índice de clave de fragmento temporal y reducir su clúster y/o su almacenamiento para adaptarse a sus necesidades de estado estable.

¡Ahora puede soltar el índice temporal con el comando db.collection.dropIndex() en mongo shell!

 db.flight_tracker.dropIndex( {"airline": 1, "flight_number": 1, "date": 1} )

preguntas frecuentes

1. ¿Cuánto tiempo lleva reshard-to-shard?

   
   

   • Depende del tamaño de su colección, la cantidad y el tamaño de los índices de su colección y la cantidad de fragmentos en su clúster, pero estamos seguros de que puede volver a fragmentar una colección de 4 TB con 10 índices en 4 fragmentos en 48 horas o menos. Dejar que el balanceador maneje las migraciones tomaría 30 días o más.

     
     

2. ¿Por qué volver a fragmentar es más rápido que dejar que el equilibrador migre los datos?

   
   

   • Las partes internas de cómo el balanceador y la fragmentación migran los datos son diferentes. La repartición lee los documentos en un orden diferente al de las migraciones de fragmentos y, dado que la repartición concluye con una eliminación de la colección anterior, no hay que esperar a que se elimine el rango para liberar espacio en el disco.

     
     

3. Quiero usar reshard-to-shard en una colección que tiene una restricción de exclusividad y los índices hash no admiten la exclusividad.

   
   

   • Si su colección tiene una restricción de unicidad, puede usar reshard-to-shard, pero tendrá que adoptar un enfoque diferente. Al agregar un campo adicional a su clave de fragmento temporal en lugar de cambiar la estrategia de partición, desbloquea la capacidad de volver a fragmentar en la clave de fragmento deseada. Por ejemplo, si su clave de fragmento deseada es:

     
     

      { launch_vehicle: 1, payload: 1}

     
     

   • Su clave de fragmento temporal sería:

      { launch_vehicle: 1, payload: 1, launch_pad: 1}

     
     

   • Tenga en cuenta las limitaciones de las consultas (p. ej., updateOne(), updateMany(), deleteOne()) que requieren que la consulta incluya la clave fragmentada. Su aplicación debe incluir la clave de partición temporal en todos los escenarios en los que una consulta requiere que la clave de partición se ejecute correctamente hasta que se complete la operación de partición.

   
   

4. ¿Cómo superviso una operación de fragmentación en curso?

   
   

   • Ejecute el siguiente comando:

      db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ])

6. ¿Cómo detengo una operación de fragmentación en curso?

   
   

   • Ejecute el siguiente comando, que aborta instantáneamente la operación de fragmentación:

      sh.abortReshardCollection("<database>.<collection>")

7. Me preocupa que la fragmentación afecte el rendimiento de mi clúster.

   
   

   • Si cumple con los requisitos de fragmentación descritos anteriormente, la operación no debería afectar el rendimiento de su clúster. Sin embargo, si su clúster se implementa en Atlas, puede aumentar la escala de su clúster temporalmente mientras ejecuta una operación de fragmento a fragmento y volver a reducir el tamaño del clúster una vez que se completa la operación.

     
     

8. ¿Qué métricas de mi clúster debo monitorear mientras se ejecuta la operación de fragmentación?

   
   

   • Espacio de almacenamiento disponible: si alguno de sus fragmentos tiene menos de 100 GB de almacenamiento disponible, debe cancelar el repartido

   • Utilización de la CPU: si su clúster consume todos los recursos informáticos disponibles, puede provocar una contención de recursos y debe cancelar la fragmentación.

   • Consumo de E/S: si su clúster está consumiendo todas las IOPS disponibles, puede causar una contención de recursos y debe cancelar la fragmentación.

     
     

9. La colección temporal aparentemente se distribuye de manera uniforme en todos mis fragmentos, ¿por qué no se completa el cambio de fragmentos?

   
   

   • Antes de que volver a fragmentar pueda pasar a la colección con la clave de fragmento deseada, debe ponerse al día con todas las escrituras que ocurrieron desde que se inició la fragmentación. Si su carga de trabajo de escritura es pesada, la fase de puesta al día puede tardar mucho tiempo en concluir.

     
     

10. Mi aplicación no puede soportar que se bloqueen las escrituras durante más de 1 segundo, ¿puedo modificar la duración en que se bloquearán las escrituras en la colección que se está fragmentando?

    
    

    • Sí, pero no esperamos que esta opción se utilice con frecuencia, ya que la operación de fragmentación de forma predeterminada intentará pasar a la nueva colección cuando se estime que la transición se puede lograr en menos de 1 segundo. Si su aplicación no puede soportar que se bloqueen las escrituras en la colección que se vuelve a fragmentar durante 2 segundos, puede modificar el parámetro reshardingCriticalSectionTimeoutMillis para bloquear las escrituras durante solo 1 segundo.

      • Tenga en cuenta que la reducción de este valor aumenta la probabilidad de que se anule la operación de fragmentación, ya que reduce el tiempo de espera que la operación de fragmentación puede esperar hasta que la sección crítica complete la transición.

    • Ejecute el siguiente comando:

       db.adminCommand({ setParameter: 1, reshardingCriticalSectionTimeoutMillis: 1000 })