[SERVER-11261] SlaveOk won't work after slave had a network exception Created: 18/Oct/13 Updated: 10/Dec/14 Resolved: 18/Oct/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 2.2.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | chensi | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux |
||
| Operating System: | ALL |
| Participants: |
| Description |
|
If network exception occurs when mongos read response from secondary, Mongos will call function <isntSecondary> . Mongos will perhaps choose PRIMARY for query, and this decision will be keeped in this woker thread's lifetime, SlaveOk won't work. |
| Comments |
| Comment by chensi [ 21/Oct/13 ] |
|
The logic as you have said is quite right. But network exception is not often, switching the query back to the previous slave node have little effective |
| Comment by Randolph Tan [ 18/Oct/13 ] |
|
Hi, Mongos will pin a node once it was chosen for the thread until an error occurred or settings changed (read preference changed). The motivation for this behavior is to avoid reading back in time as much as possible. Example of "reading back in time" if the nodes are not pinned. Ops: Replset status: 1. Mongos chose S2 for a query. Updated doc A is returned. As you can see, this can be very confusing, so mongos tries it's best to stick to the same node after it is chosen to avoid this situation. |