[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:
steps (done via mongo shell): 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: |
| 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'? |