[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:
1. insert doc A
2. update doc A.

Replset status:
P: ok
S1: applied up to op#1
S2: applied up to op#2

1. Mongos chose S2 for a query. Updated doc A is returned.
2. A query is performed again, this time, S1 is chosen, old 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.

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