[SERVER-23326] applyOps should use a single WriteUnitOfWork where possible Created: 23/Mar/16 Updated: 08/Oct/17 Resolved: 04/Jun/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.8 |
| Type: | Bug | Priority: | Blocker - P1 |
| Reporter: | Mathias Stearn | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 0 |
| Labels: | RF, bkp | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||
| Backport Requested: |
v3.2
|
||||||||||||||||||||||||||||
| Sprint: | Integrate+Tuning 14 (05/13/16), Integrate+Tuning 15 (06/03/16), Integrate+Tuning 16 (06/24/16) | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Description |
|
Currently we break some guarantees of atomicity by using separate WUOWs for each op and for the final logOp. This can result in a server performing the modification but not adding it to its oplog if the server is shut down in the middle of an applyOps. We can't use a single WUOW in the general case because applyOps needs to support operations like building an index that are illegal inside of a WUOW. However, it should be possible to detect if all ops are simple single-document CRUD ops and use a single WUOW in that case. This would cover all uses of applyOps that are used when writing to the config servers. |
| Comments |
| Comment by Geert Bosch [ 20/Dec/16 ] |
|
Given that backup relies on applyOps being non-atomic, this change would break OpsManager. It is too big of a change to backport in a general fashion, IMO. We could consider doing this only for config servers, or similar. |
| Comment by Githook User [ 04/Jun/16 ] |
|
Author: {u'username': u'GeertBosch', u'name': u'Geert Bosch', u'email': u'geert@mongodb.com'}Message: |
| Comment by Martin Bligh [ 28/Mar/16 ] |
|
If we want to make this more consistent, it'd seem to make sense to make a hard rule (controlled by a bool flag) - ie we either do it in one WUOW or fail the command if we can't do that? |
| Comment by Scott Hernandez (Inactive) [ 24/Mar/16 ] |
|
We have a mechanism in replication to address this as we store the batch boundaries (in the minvalid document), which indicates the operations being applied in the batch. Is there some reason this is not sufficient? Or are you really suggesting some optimization for the applyOps command (which is used by sharding), not replication related? |
| Comment by Mathias Stearn [ 23/Mar/16 ] |
|
geert.bosch I put this on the sharding backlog for prioritization since that is the main use case that will benefit, but this will probably end up being implemented by the Integration team. |