[SERVER-16349] Expose replSetMaintenance status counter in db.serverStatus() Created: 29/Nov/14 Updated: 16/Feb/15 Resolved: 16/Feb/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics |
| Affects Version/s: | 2.8.0-rc1 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Alexander Komyagin | Assignee: | Andy Schwerin |
| Resolution: | Done | Votes: | 0 |
| Labels: | PM-30 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
It appears that the command implements a cumulative effect, i.e. for two successive replSetMaintenance:1 commands there must be two successive replSetMaintenance:0 commands. The status counter should be available through db.serverStatus(). |
| Comments |
| Comment by Alexander Komyagin [ 02/Dec/14 ] |
|
Closed as per my discussion with Andy. The rs.status command should provide the output needed. |
| Comment by Andy Schwerin [ 01/Dec/14 ] |
|
The effect is indeed cumulative. I believe the original idea was to allow independent maintenance scripts to bring the server in and out of maintenance mode without interfering, and to allow for recursive locking so maintenance scripts could delegate to other scripts. A handful of internal commands also increment and decrement the count, somewhat complicating matters for display and safety purposes. An alternative we should also consider is making maintenance mode a flag, instead of a counter, and simply having the "set" form of the maintenance command fail if the bit is already set. This approach would be built on the assumption that multiple scripts should not simultaneously engage in maintenance operations. |