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
/
Manual de base de datos
/

Consideraciones de producción (Clústeres fragmentados)

Puedes realizar transacciones multi-documento en clústeres shardeados.

La siguiente página enumera las preocupaciones específicas relativas a la ejecución de transacciones en un clúster. Estas preocupaciones se suman a las mencionadas en Consideraciones de producción.

Las transacciones que se dirigen a una sola partición deben tener el mismo rendimiento que las transacciones de set de réplicas.

Las transacciones que afectan a múltiples particiones conllevan un mayor costo de rendimiento.

Nota

En un clúster particionado, las transacciones que abarcan múltiples particiones generarán un error y se abortarán si alguna de las particiones involucradas contiene un árbitro.

Para especificar un límite de tiempo, especifique un maxTimeMS límite en commitTransaction.

Si maxTimeMS no se especifica, MongoDB transactionLifetimeLimitSeconds utilizará.

Si maxTimeMS se especifica pero el resultado sería una transacción que transactionLifetimeLimitSeconds excede, MongoDB transactionLifetimeLimitSeconds utilizará.

Para modificar para un clúster fragmentado, el parámetro debe modificarse para todos los miembros del conjunto de réplicas de transactionLifetimeLimitSeconds fragmentos.

Las transacciones multidocumento admiten niveles de nivel de consistencia de lectura "local", "majority" y "snapshot".

Para las transacciones en un clúster fragmentado, sólo la "snapshot" nivel de consistencia de lectura proporciona una instantánea coherente en varios shards.

Para obtener más información sobre el nivel de consistencia de lectura y las transacciones, consulta Transacciones y niveles de consistencia de lectura.

No puedes ejecutar transacciones en un clúster que tenga una partición con writeConcernMajorityJournalDefault configurado en false (como una partición con un nodo votante que utiliza el motor de almacenamiento en memoria).

Nota

Independientemente del nivel de confirmación de escritura (write concern) especificado para la transacción, la operación de confirmación para una transacción de clúster fragmentado incluye algunas partes que usan el nivel de confirmación de escritura (write concern) {w: "majority", j: true}.

No puedes cambiar una clave de fragmentación mediante una transacción si el set de réplicas tiene un árbitro. Los árbitros no pueden participar en las operaciones de datos requeridas para las transacciones de múltiples fragmentos.

Las transacciones cuyas operaciones de escritura abarcan varios fragmentos generarán un error y se abortarán si alguna operación de transacción lee o escribe en una partición que contiene un árbitro.

Advertencia

Para utilizar mongodump y mongorestore como estrategia de respaldo para clústeres particionados, consulte Realizar una copia de seguridad de un clúster particionado autogestionado con un vaciado de base de datos.

Los clústeres particionados también pueden utilizar uno de los siguientes procesos coordinados de copia de seguridad y restauración, que mantienen las garantías de atomicidad de las transacciones entre particiones:

La migración por fragmentos adquiere bloqueos de colección exclusivos durante ciertas etapas.

Si una transacción en curso tiene un bloqueo sobre una colección y comienza una migración de fragmentos que involucra esa colección, estas etapas de migración deben esperar a que la transacción libere los bloqueos sobre la colección, lo que afecta el rendimiento de las migraciones de fragmentos.

Si una migración de fragmentos se entrelaza con una transacción (por ejemplo, si una transacción comienza mientras una migración de fragmentos ya está en curso y la migración se completa antes de que la transacción bloquee la colección), la transacción genera un error durante la confirmación y se aborta.

Según cómo se intercalan las dos operaciones, se incluyen algunos errores de muestra (los mensajes de error se han abreviado):

  • an error from cluster data placement change ... migration commit in progress for <namespace>

  • Cannot find shardId the chunk belonged to at cluster time ...

Tip

Durante la confirmación de una transacción, las operaciones de lectura externas pueden intentar leer los mismos documentos que modificará la transacción. Si la transacción guarda en múltiples particiones, entonces durante el intento de confirmación en las particiones:

  • Las lecturas externas que usan el nivel de consistencia de lectura "snapshot" o "linearizable" esperan hasta que todas las escrituras de una transacción sean visibles.

  • Las lecturas externas que forman parte de sesiones causalmente coherentes (aquellas que incluyen afterClusterTime) esperan hasta que todas las escrituras de una transacción sean visibles.

  • Las lecturas externas que usan otros niveles de consistencia de lectura no esperan a que todas las escrituras de una transacción sean visibles, sino que leen la versión de los documentos anterior a la transacción.

Ver también Consideraciones de Producción.

Volver

Consideraciones de Producción

En esta página