[SERVER-31436] dropDatabase must check `ReplicationCoordinator::canAcceptWritesFor` after reacquiring global lock Created: 06/Oct/17 Updated: 30/Oct/23 Resolved: 16/Oct/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.0-rc1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Benety Goh | Assignee: | Benety Goh |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||
| Sprint: | Repl 2017-11-13 | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Linked BF Score: | 0 | ||||||||||||||||||||||||
| Description |
|
After waiting for all collection drops to replicate to a majority of the replica set, the dropDatabase command reacquires the global lock before completing the rest of the database drop and logging the dropDatabase oplog entry. It is possible that the primary has stepped down while waiting for the collection drops. We should check ReplicationCoordinator::canAcceptWritesFor after reacquiring the global lock to avoid hitting a fatal assertion in logOp() in this case. |
| Comments |
| Comment by Githook User [ 16/Oct/17 ] |
|
Author: {'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}Message: |
| Comment by Githook User [ 13/Oct/17 ] |
|
Author: {'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}Message: |