[SERVER-28639] Prevent multiple noopWrites to opLog Created: 05/Apr/17 Updated: 08/Jan/24 Resolved: 21/Jun/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.10 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Misha Tyulenev | Assignee: | Misha Tyulenev |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Sprint: | Sharding 2017-06-19, Sharding 2017-07-10 |
| Participants: |
| Description |
|
Filed as a follow up of It may be possible that multiple threads are getting the readConcern: {afterClusterTime: <clusterTime>} while the <clusterTime> > lastAllpliedOpTime. In this case the multiple noop writes should be prevented. Implementation plan: As the makeNoopWriteIfNeeded can be scheduled from multiple threads it should contain the context that can be shared in order to make threads wait on the started operation. Hence makeNoopWriteIfNeeded needs to be a method of a newly added CallbackSerializer class, which contains the runtime state. The instance of the class will be placed on the ServiceContext.
the scheduling will be done from the existing path in read_concern:
|
| Comments |
| Comment by Githook User [ 21/Jun/17 ] |
|
Author: {u'username': u'mikety', u'name': u'Misha Tyulenev', u'email': u'misha@mongodb.com'}Message: |
| Comment by Mira Carey [ 15/Jun/17 ] |
|
In principle a generic type would interesting. I suspect that std::async with a deferred policy, or std::call_once (with a once_flag) could provide a good backend, but we can tackle that when we get there. |
| Comment by Misha Tyulenev [ 15/Jun/17 ] |
|
Thanks kaloian.manassiev |
| Comment by Kaloian Manassiev [ 15/Jun/17 ] |
|
LGTM, except that OplogNoopWriter is not really an oplog writer anymore, but just a "callback serializer". Perhaps put it in mongo/util/concurrency. Also if you have this class, you can also make sure that secondaries do not send more than one refresh at a time |
| Comment by Misha Tyulenev [ 15/Jun/17 ] |
|
Updated the description per feedback |
| Comment by Kaloian Manassiev [ 14/Jun/17 ] |
My question was where would you hook the call into the OplogNoopWriter (not where will it be stored). The reason I am asking is because I suspect it would have to be in AppendOplogNoteCmd, which the writer is using and that would make the command serialized as well. I think this is probably alright, but we should check with repl if that is the case.
I think the problem in that case might be the number of concurrent connections that they would open against the primary to hit it with refresh requests. Probably not that big of a problem since the writes on the primary will be serialized. |
| Comment by Misha Tyulenev [ 13/Jun/17 ] |
|
1. OplogNoopWriter will go to ServiceContext |
| Comment by Kaloian Manassiev [ 13/Jun/17 ] |
|
I have two questions:
Apart from that the proposed OplogNoopWriter implementation looks good to me, except that one of the waitFor calls seems to be happening under a mutex. |
| Comment by Misha Tyulenev [ 13/Jun/17 ] |
|
kaloian.manassiev please lmk the feedback |