[SERVER-22264] First Readconcern majority query hangs Created: 21/Jan/16  Updated: 03/Feb/16  Resolved: 03/Feb/16

Status: Closed
Project: Core Server
Component/s: Querying, Replication
Affects Version/s: 3.2.1
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Dylan Tong Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Operating System: ALL
Steps To Reproduce:

Reproduced this consistently a few times in AWS:

config:

  • 3 member replicaSet
  • 2 delayed secondaries (set 3600)
  • m3.medium
  • version 3.2.1

steps (done via mongo shell):
1. enableMajorityReadConcern
2. insert something
3. query inserted document on primary using "local" readConcern as a sanity check
4. query inserted documented with readConcern majority

expected results: the query should hang for a very long time (at least it happen to me after recreating this environment multiple times in AWS via CloudManager)

Additional observations:
The query hanged indefinitely for me when delay was 3600s. I was able to get the query to complete on 3.2.0 with delay set to 60s. The first query hanged for ~30s and returned no results as expected. Subsequent queries (on updates performed on the document) with this different configuration after the first returned without observed delay.

Participants:

 Description   

The first query with readConcern majority will hang for a long time when there is significant replication lag/delay



 Comments   
Comment by Mathias Stearn [ 02/Feb/16 ]

This is expected behavior. We block majority reads to newly created collections until their creation has be replicated to a majority of nodes. In your case that takes an hour, so reads from that collection will be blocked for an hour. We suggest combining readConcern:majority with w:majority writes because then we can guarantee that you can read immediately after the write is confirmed. Of course in this case, the write will then take an hour.

In practice, I'd suggest never configuring a replica set such that you can't form a majority without including delayed secondaries. It is probably best to have majority+1 nodes with no delay so that you can lose a node without losing majority.

Comment by Dylan Tong [ 21/Jan/16 ]

no, it was done with default write concern through mongo shell.

eg. db.stuff.insert(

{stuff:"some things..."}

);

Comment by Mathias Stearn [ 21/Jan/16 ]

Was the insert (step 2) done with w:'majority'?

Generated at Thu Feb 08 03:59:52 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.