A partir de la versión 4.2, MongoDB brinda la capacidad de realizar transacciones de múltiples documentos para clústeres fragmentados.
La siguiente página enumera preocupaciones específicas para ejecutar transacciones en un clúster fragmentado. Estas preocupaciones se suman a las enumeradas en Consideraciones de producción .
Para transacciones en implementaciones de MongoDB 4.2 (conjuntos de réplicas y clústeres fragmentados) , los clientes deben usar controladores MongoDB actualizados para MongoDB 4.2.
En clústeres fragmentados con varias mongosinstancias, la realización de transacciones con controladores actualizados para MongoDB 4.0 (en lugar de MongoDB 4.2) fallará y puede generar errores, que incluyen:
NOTA: Su controlador puede devolver un error diferente. Consulte la documentación de su controlador para obtener más detalles.
| Código de error | Mensaje de error |
|---|---|
| 251 | cannot continue txnId -1 for session ... with txnId 1 |
| 50940 | cannot commit with no participants |
Las transacciones que tienen como objetivo un solo fragmento deben tener el mismo rendimiento que las transacciones de conjuntos de réplicas.
Las transacciones que afectan a múltiples fragmentos incurren en un mayor costo 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 implicados contiene un árbitro.
Para especificar un límite de tiempo, especifique un maxTimeMSlímite en commitTransaction.
Si maxTimeMSno se especifica, MongoDB utilizará la extensión transactionLifetimeLimitSeconds.
Si maxTimeMSse especifica pero daría como resultado una transacción que exceda transactionLifetimeLimitSeconds, MongoDB usará el transactionLifetimeLimitSeconds.
Para modificar transactionLifetimeLimitSecondspara un clúster fragmentado, el parámetro debe modificarse para todos los miembros del conjunto de réplicas de fragmentos.
Transacciones multi-documento de apoyo "local", "majority"y "snapshot"leen los niveles de preocupación.
Para las transacciones en un clúster fragmentado, solo la "snapshot"preocupación de lectura proporciona una instantánea coherente en varios fragmentos.
Para obtener más información sobre problemas de lectura y transacciones, consulte Transacciones y problemas de lectura .
No puede ejecutar transacciones en un clúster fragmentado que tiene un fragmento con writeConcernMajorityJournalDefaultestablecido en false (como un fragmento con un miembro votante que usa el motor de almacenamiento en memoria ).
NOTA: Independientemente del problema de escritura especificado para la transacción , la operación de confirmación para una transacción de clúster fragmentado incluye algunas partes que utilizan el {w: "majority", j: true}problema de escritura.
Las transacciones cuyas operaciones de escritura abarcan varios fragmentos generarán errores y se cancelarán si alguna operación de transacción lee o escribe en un fragmento que contiene un árbitro.
Consulte también Fragmentos de árbitro primario-secundario-árbitro de tres miembros para conocer las restricciones de transacción de los fragmentos que han desactivado la mayoría de interés de lectura.
Para un clúster fragmentado con fragmentos de PSA de tres miembros, es posible que haya desactivado la preocupación de lectura "mayoría" (es decir, --enableMajorityReadConcern falseo replication.enableMajorityReadConcern: false) para evitar la presión de la caché.En clústeres fragmentados,
-
Si una transacción involucra un fragmento que ha inhabilitado la preocupación de lectura "mayoría" , no puede utilizar la preocupación de lectura
"snapshot"para la transacción. Solo puede usar la preocupación de lectura"local"o"majority"para la transacción. Si usa la preocupación de lectura"snapshot", la transacción se produce un error y se cancela.readConcern level 'snapshot' is not supported in sharded clusters when enableMajorityReadConcern=false. -
Las transacciones cuyas operaciones de escritura abarcan varios fragmentos generarán errores y se abortarán si alguna de las operaciones de lectura o escritura de la transacción involucra un fragmento que ha deshabilitado el problema de lectura
"majority".
Para comprobar si la preocupación de lectura "mayoría" está desactivada,
Puede ejecutar db.serverStatus()y comprobar el storageEngine.supportsCommittedReadscampo. Si false, lea la preocupación "mayoría" está deshabilitada.
ADVERTENCIA: mongodumpy no puede ser parte de una estrategia de copia de seguridad para clústeres fragmentados 4.2+ que tienen transacciones fragmentadas en curso, ya que las copias de seguridad creadas con no mantienen las garantías de atomicidad de las transacciones entre fragmentos.mongorestore __mongodump__
Para clústeres fragmentados 4.2+ con transacciones fragmentadas en curso, utilice uno de los siguientes procesos coordinados de copia de seguridad y restauración que mantienen las garantías de atomicidad de las transacciones entre fragmentos:
La migración de fragmentos adquiere bloqueos de colección exclusivos durante determinadas etapas.
Si una transacción en curso tiene un bloqueo en una colección y se inicia una migración de fragmentos que implica esa recopilación, estas etapas de migración deben esperar a que la transacción libere los bloqueos de la colección, lo que afectará 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 se produce un error durante la confirmación y se cancela.
Dependiendo de cómo se intercalen las dos operaciones, algunos errores de muestra incluyen (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 ...
CONSEJO Ver tambiénshardingStatistics.countDonorMoveChunkLockTimeout__
Durante la confirmación de una transacción, las operaciones de lectura externas pueden intentar leer los mismos documentos que serán modificados por la transacción. Si la transacción escribe en varios fragmentos, durante el intento de confirmación en los fragmentos
- Exterior lee que el uso leyó preocupación
"snapshot"o"linearizable", o son parte de las sesiones causalmente consistentes (es decir, incluyen afterClusterTime ) espera para todas las escrituras de una transacción para que sea visible. - Las lecturas externas que utilizan otras preocupaciones de lectura no esperan a que todas las escrituras de una transacción sean visibles, sino que leen la versión anterior a la transacción de los documentos disponibles.
CONSEJO Ver también: Transacciones y atomicidad__
Consulte también Consideraciones de producción .