Puedes realizar transacciones multi-documento en clústeres shardeados.
En la siguiente página se enumeran las preocupaciones específicas de la ejecución de transacciones en un clúster fragmentado. Estas preocupaciones se suman a las enumeradas en Consideraciones de producción.
Rendimiento
Fragmento único
Las transacciones que se dirigen a una sola partición deben tener el mismo rendimiento que las transacciones de set de réplicas.
Fragmentos múltiples
Las transacciones que afectan a varios fragmentos implican un mayor coste de rendimiento.
Nota
En un clúster fragmentado, las transacciones que abarcan varios fragmentos generarán errores y se cancelarán si alguno de los fragmentos involucrados contiene un árbitro.
Límite de tiempo
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.
Leer inquietudes
Las transacciones multidocumento admiten niveles de nivel de consistencia de lectura "local", "majority" y "snapshot".
Para las transacciones en un clúster fragmentado, solo la preocupación de lectura proporciona una instantánea consistente en múltiples "snapshot" fragmentos.
Para obtener más información sobre la preocupación de lectura y las transacciones,consulte Transacciones y preocupación de lectura.
Escribir inquietudes
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 problema de escritura especificado para la transacción, la operación de confirmación de una transacción de clúster fragmentado incluye algunas partes que utilizan el {w:
"majority", j: true} problema de escritura.
Árbitros
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.
Copias de seguridad y restauraciones
Advertencia
Para utilizar mongodump y como estrategia de respaldo para clústeres fragmentados, consulte Realizar mongorestore una copia de seguridad de un clúster fragmentado autoadministrado con un volcado 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:
Migraciones de fragmentos
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 ...
Lecturas externas durante la confirmación
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.
Información Adicional
Véase también Consideraciones de producción.