Mongo Transactions in Sharded Environment

[Laks]

Hi Team,

I’m using mongo 4.4 transactions in a sharded environment with replica set (with arbiters). to update multi document transactions. Following is the error message returned.

TransactionOptions txnOptions = TransactionOptions.builder()
        .readPreference(ReadPreference.primary())
        .readConcern(ReadConcern.LOCAL) // Tried ReadConcern with MAJORITY as well, same issue.
        .writeConcern(WriteConcern.MAJORITY)
        .build();

com.mongodb.MongoCommandException: Command failed with error 148 (ReadConcernMajorityNotEnabled): 'Transaction was aborted :: caused by :: from shard <Shard>:: caused by :: 'prepareTransaction' is not supported for replica sets with arbiters' on server <Server> The full response is {"ok": 0.0, "errmsg": "Transaction was aborted :: caused by :: from shard <Shard>::: caused by :: 'prepareTransaction' is not supported for replica sets with arbiters", "code": 148, "codeName": "ReadConcernMajorityNotEnabled", "operationTime": {"$timestamp": {"t": 1660211382, "i": 6}}, "$clusterTime": {"clusterTime": {"$timestamp": {"t": 1660211382, "i": 6}}, "signature": {"hash": {"$binary": {"base64": <>, "subType": "00"}}, "keyId": <keyID> }}, "recoveryToken": {"recoveryShardId": <Shard>}}

[Stennie_X (Stennie)]

Hi @laks,

Per Transactions: Production Considerations (Sharded Clusters) this is an expected error:

On a sharded cluster, transactions that span multiple shards will error and abort if any involved shard contains an arbiter.

Arbiters do not write data, so they can cause significant operational challenges for use cases that rely on majority acknowledgement of writes. If your transaction use case requires updating documents across multiple shards, you will have to replace any arbiters with secondaries.

I strongly recommend avoiding arbiters in production as they introduce significant operational challenges. For more background, see Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie_X.

Regards,
Stennie