Test single shard transactions with arbiters and enableMajorityReadConcern:false replica sets with lag

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 4.1.7
    • Affects Version/s: None
    • Component/s: Replication
    • None
    • Fully Compatible
    • Repl 2018-12-03, Repl 2018-12-17, Repl 2019-01-14, Repl 2019-01-28
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      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.

            Assignee:
            Vesselina Ratcheva (Inactive)
            Reporter:
            Will Schultz
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: