[SERVER-22180] MongoS could recover it's own balancer lock on restart Created: 14/Jan/16 Updated: 06/Dec/22 Resolved: 09/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | 3.0.8 |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Minor - P4 |
| Reporter: | Andrew Ryder (Inactive) | Assignee: | [DO NOT USE] Backlog - Sharding Team |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Sharding
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Participants: | |||||
| Description |
|
When a MongoS is restarted (for any reason) and happens to be holding the Balancer lock at the time, it could pick this up again if it comes back before another MongoS forces it. At the moment anything that was inflight is effectively cancelled due to the dropped lock, and another MongoS (or possibly the same MongoS) will force the lock 15 minutes later. Can a MongoS safely identify itself as the owner of the balancer lock if it were to check for such state at start-up? |
| Comments |
| Comment by Kaloian Manassiev [ 14/Jan/16 ] |
|
This has been fixed in 3.2 in a different way - now upon graceful shutdown of mongos, it will free its distributed locks, instead of trying to recover them on startup. The problem with recovering locks by mongos is that routers have no storage so there is no way to 'remember' what the process id was. |