[SERVER-38041] Test single shard transactions with arbiters and enableMajorityReadConcern:false replica sets with lag Created: 08/Nov/18  Updated: 29/Oct/23  Resolved: 14/Jan/19

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 4.1.7

Type: Task Priority: Major - P3
Reporter: William Schultz (Inactive) Assignee: Vesselina Ratcheva (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-37897 Disable table logging for data files ... Closed
Related
related to SERVER-37549 Compute atClusterTime for sharded tra... Closed
Backwards Compatibility: Fully Compatible
Sprint: Repl 2018-12-03, Repl 2018-12-17, Repl 2019-01-14, Repl 2019-01-28
Participants:

 Description   

Transactions that touch a single shard that contains an arbiter or contains a node with enableMajorityReadConcern:false will be allowed in 4.2. We should test that:

  1. A single shard transaction can succeed against a replica set that contains an arbiter.
  2. A single shard transaction can succeed against a replica set whose primary has enableMajorityReadConcern:false and whose secondary is lagged. We should test this to make sure that the transaction is selecting a read timestamp based on lastApplied, as opposed to starting at the majority commit point. If it started at the majority commit point, we would not be able to obtain a snapshot, since we won't keep history back that far.


 Comments   
Comment by Githook User [ 14/Jan/19 ]

Author:

{'username': 'vessy-mongodb', 'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva'}

Message: SERVER-38041 Test single shard transactions with arbiters and enableMajorityReadConcern:false replica sets with lag
Branch: master
https://github.com/mongodb/mongo/commit/b1e8aca52cef1c2a09ac3d06ffba95f528c0e766

Comment by William Schultz (Inactive) [ 11/Dec/18 ]

To clarify the intent of this ticket, sharded transactions against EMRC=false replica sets will mostly be covered by the passthrough coverage being added in SERVER-37343, but we want to add a targeted test case from transactions against an EMRC=false replica set with some lag.

Comment by Tess Avitabile (Inactive) [ 14/Nov/18 ]

This depends on SERVER-37897, which will ensure that the storage engine respects maxTargetSnapshotHistoryWindowInSeconds when enableMajorityReadConcern=false.

Generated at Thu Feb 08 04:47:47 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.