-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Fully Compatible
-
v4.2
-
Sharding 2019-06-17, Sharding 2019-07-01, Sharding 2019-07-15, Sharding 2019-07-29
If read concern majority is disabled, transactions with writes that span multiple shards should error.
But, when I have a txn that spans multiple shards (with rc majority disabled), I get a TransientTransactionError instead of a "'prepareTransaction' is not supported with 'enableMajorityReadConcern=false'".
Steps to reproduce:
- Start a sharded cluster with 2 PSA shards (enableMajorityReadConcern=false for both shards)
- Connect mongo shell to the mongos and run:
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } ); coll1 = session.getDatabase("mydb1").foo; coll2 = session.getDatabase("mydb2").bar; test = session.getDatabase("test").students2; // Using readconcern local and write concern majority session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } ); try { coll1.insertOne( { abc: 1 } ); // ShardB coll2.insertOne( { xyz: 999 } ); // ShardB test.insertOne( { x: 1 }) // ShardA } catch (error) { // Abort transaction on error session.abortTransaction(); throw error; } // Commit the transaction using write concern set at transaction start session.commitTransaction(); session.endSession();
This returns:
MongoDB Enterprise mongos> session.commitTransaction(); 2019-05-29T13:24:28.121-0400 E QUERY [js] uncaught exception: Error: command failed: { "errorLabels" : [ "TransientTransactionError" ], "ok" : 0, "errmsg" : "Transaction was aborted", "code" : 251, "codeName" : "NoSuchTransaction", "operationTime" : Timestamp(1559150668, 4), "$clusterTime" : { "clusterTime" : Timestamp(1559150668, 4), "signature" : { "hash" : BinData(0,"jPzNbm4zF7knG/Lw+fOM/+PuNKw="), "keyId" : NumberLong("6696440883090292753") } }, "recoveryToken" : { "recoveryShardId" : "shardB" } }
I would have expected this to error once and stop immediately (similar to what the txn does if using rc snapshot with rc majority disabled)
Am attaching the log of shardB primary (had turned the verbosity level to 4)
From the log, the txnCoordinator sends prepare txn to shardB again even after the coordinator received the assertion (which is the error I would expect to see bubble up and stop everything).
2019-05-29T13:50:11.266-0400 D3 TXN [TransactionCoordinator] Coordinator going to send command { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" } } to shard shardA 2019-05-29T13:50:11.268-0400 D3 TXN [TransactionCoordinator] Coordinator going to send command { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" } } to local shard shardB 2019-05-29T13:50:11.269-0400 D2 COMMAND [TransactionCoordinator] run command admin.$cmd { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" }, $db: "admin" } 2019-05-29T13:50:11.271-0400 D2 COMMAND [TransactionCoordinator] command: prepareTransaction 2019-05-29T13:50:11.272-0400 I TXN [TransactionCoordinator] transaction parameters:{ lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, readConcern: { level: "snapshot" } }, readTimestamp:Timestamp(0, 0), ninserted:2 keysInserted:2 terminationCause:aborted timeActiveMicros:162 timeInactiveMicros:2089046 numYields:0 locks:{ ReplicationStateTransition: { acquireCount: { w: 4 } }, Global: { acquireCount: { r: 2, w: 1 } }, Database: { acquireCount: { r: 1, w: 2 } }, Collection: { acquireCount: { r: 1, w: 2 } }, Mutex: { acquireCount: { r: 9 } } } storage:{} wasPrepared:0, 2089ms 2019-05-29T13:50:11.273-0400 D1 COMMAND [TransactionCoordinator] assertion while executing command 'prepareTransaction' on database 'admin' with arguments '{ prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" }, $db: "admin" }': Location50993: 'prepareTransaction' is not supported with 'enableMajorityReadConcern=false' 2019-05-29T13:50:11.274-0400 I COMMAND [TransactionCoordinator] command admin.$cmd command: prepareTransaction { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" }, $db: "admin" } numYields:0 ok:0 errMsg:"'prepareTransaction' is not supported with 'enableMajorityReadConcern=false'" errName:Location50993 errCode:50993 reslen:460 locks:{ ReplicationStateTransition: { acquireCount: { w: 4 } }, Global: { acquireCount: { r: 2, w: 1 } }, Database: { acquireCount: { r: 1, w: 2 } }, Collection: { acquireCount: { r: 1, w: 2 } }, Mutex: { acquireCount: { r: 9 } } } flowControl:{ acquireCount: 1 } storage:{} protocol:op_msg 1ms 2019-05-29T13:50:11.275-0400 D3 TXN [TransactionCoordinator] Coordinator shard received Location50993: 'prepareTransaction' is not supported with 'enableMajorityReadConcern=false' from shard shardB for { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" } } 2019-05-29T13:50:11.276-0400 D3 TXN [TransactionCoordinator] Coordinator going to send command { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" } } to local shard shardB 2019-05-29T13:50:11.277-0400 D2 COMMAND [TransactionCoordinator] run command admin.$cmd { prepareTransaction: 1, lsid: { id: UUID("003f3817-1a36-45c2-a439-d91dd9fffa16"), uid: BinData(0, DE9C6A9004CD518295FECA13EEAA8A134CC2D0115BD29073D69938C577121EC2) }, txnNumber: 0, autocommit: false, writeConcern: { w: "majority" }, $db: "admin" } 2019-05-29T13:50:11.277-0400 D2 COMMAND [TransactionCoordinator] command: prepareTransaction
- depends on
-
SERVER-41204 Track the participant that voted abort and why in the mongod two-phase commit metrics and report it in slow logging
- Closed