[SERVER-26005] FTDC shouldn't conflict with secondary application Created: 07/Sep/16 Updated: 25/Sep/18 Resolved: 16/Sep/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.3.14 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Mathias Stearn | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Backport Requested: |
v3.2
|
||||||||||||||||||||
| Sprint: | Repl 2016-09-19 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
Currently FTDC doesn't declare that it can bypass the PBWM lock. This has two effects: replication can't apply while FTDC is running (minor), FTDC can't capture data while replication is applying (potentially major). Since some replication batches such as index builds take a long time, this can result in large holes in FTDC data. |
| Comments |
| Comment by Githook User [ 16/Sep/16 ] |
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: |
| Comment by Mathias Stearn [ 08/Sep/16 ] |
|
The PBWM lock is automatically acquired every time you get a global lock: https://github.com/mongodb/mongo/blob/r3.3.12/src/mongo/db/concurrency/d_concurrency.cpp#L78-L81. You can opt-out of this today by calling txn->lockState()->setIsBatchWriter(true). My plan is to give that a less specific name such as "shouldConflictWithSecondaryApplication" or "isOkWithObservingInconsistentStateOnSecondaries" (actual name TBD). |
| Comment by Mark Benvenuto [ 08/Sep/16 ] |
|
How should FTDC declare that it can bypass the PBWM lock? Does serversStatus or one of the other commands actually take this lock? |