[SERVER-5972] Cannot drop system.js collection Created: 31/May/12 Updated: 02/Sep/22 Resolved: 02/Sep/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Spencer Brody (Inactive) | Assignee: | Gregory Noma |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||
| Sprint: | Execution Team 2022-09-05 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Description |
|
| Comments |
| Comment by Githook User [ 02/Sep/22 ] |
|
Author: {'name': 'Gregory Noma', 'email': 'gregory.noma@gmail.com', 'username': 'gregorynoma'}Message: |
| Comment by Asya Kamsky [ 25/Apr/18 ] |
|
It appears you can drop any system. prefixed collections now (tested 3.6.3). edit apparently not every collection, so never mind my comment - still need to rename before dropping (at least system.js, etc). |
| Comment by Roman Kuzmin [ 17/Nov/13 ] |
|
There is a way to drop "system.js". As far as this issue https://jira.mongodb.org/browse/SERVER-5955 is not yet resolved, we can rename "system.js" to something else and then drop the renamed collection. |
| Comment by Manan S [ 30/Sep/13 ] |
|
Interestingly the system.profile capped collection itself isnt getting replicated. Any idea why? group:PRIMARY> db.system.profile.count() group:SECONDARY> db.system.profile.count() |
| Comment by Manan S [ 30/Sep/13 ] |
|
Another strange thing I've noticed is this capped collection if created by any other tool such as rockmongo when you change the size of this collection, the data didnt get replicated over to the secondaries. See this difference between the primary and secondary and there isn't any replication lag because all other normal collections data is good on secondaries. group:PRIMARY> db.system.profile_rockmongo_bk_52461190e998a.count() 869423 group:SECONDARY> db.system.profile_rockmongo_bk_52461190e998a.count() 0 To give a brief, this system.profile_rockmongo_bk collection was created automatically when the size of this capped collection was changed; so it copied the existing profiler data into this new _bk collection and spun a new system.profile collection for the modified size. But you can only query this _bk collection against Primary but not on secondary even though the show collections would show the name in the listing. Anyone any idea why the data is not being replicated? |
| Comment by Daniel Pasette (Inactive) [ 29/Sep/13 ] |
|
You should be able to change the size of the profile collection without a backup being created. Sounds like a quirk of rockmongo. http://docs.mongodb.org/manual/tutorial/manage-the-database-profiler/#profiler-overhead |
| Comment by Manan S [ 27/Sep/13 ] |
|
Yeah I'm facing similar issue if you try to change the size of the system.profile capped collection, it will create a backup of the existing and the new entries will then pour into the fresh system.profile. Now I've several such system.profile_bk_xxx collections that are old and no longer required. But if you try to drop it, it throws an error: PRIMARY> db.system.profile_rockmongo_bk_52422c217960b.drop() This needs to be resolved asap. |
| Comment by Roman Kuzmin [ 01/Jun/12 ] |
|
Yet another argument: according to |
| Comment by Roman Kuzmin [ 01/Jun/12 ] |
|
I agree that it is not a very important issue. But it violates the least surprise principle, in the first place. Also, though I do not have example use cases but in theory it is possible that in some cases a user may want to invoke some steps based on the simple fact of availability of this collection. But if it cannot be dropped after creation (even creation by mistake) then such scenarios are not possible or get a bit more complex (e.g. an extra check is needed whether or not system.js contains any data). |
| Comment by Eliot Horowitz (Inactive) [ 31/May/12 ] |
|
Not sure it makes sense to special case it. |